FEATURE: -f -f - fork after successful open of fwd port/display/agent

[Dan Astoorian]

On Fri, 01 Feb 2002 17:34:47 EST, mouring writes:
> 
> =)  -f -f does not bother me as long as it is well documented.  However I
> hate the --some-command-that-we-may-not-use-offen-but-hell-we-wanted-an-optio
> n.

In general, IMHO, options should be idempotent; i.e., "-Z -Z" should
have the same effect as '-Z'.

Among the reasons for this: a wrapper program should be able to add
options to a command line in order to assure a specific behaviour.  For
example, if a wrapper wants to suppress diagnostics, it should just be
able to add "-q" option.  If wrappers are nested, and each adds its own
"-q" option, they shouldn't interfere with each other.

There is historical precedent for more -v's making output more verbose,
but the idea of '-f -f' having a *qualitatively* different meaning than
'-f' is a little unsettling.  You're not using "-f -f" to mean "-f, only
more so"; it appears as if you just didn't want to use up another letter
for a option with nearly identical semantics.

As for --long-options, Ben is quite right.  We already have
-[alphAbetsouP] and -o `cat /usr/dict/words`, and adding GNUisms won't
supply anything that these existing mechanisms can't deal with perfectly
well.

As for Nicolas's comment:

> > Originally I implemented (locally) this as a -o option and the option
> > name was horrible, "WaitForPortOpenBeforeFork", because I couldn't think
> > of a very short, yet very descriptive option name for this feature.

Think harder :-)

My opinion, for what it's worth, is that the difficulty in giving the
feature a simple name reflects the fact that it's not a very elegant
feature in the context of the existing design.

(A cleaner design would be for -f to make ssh background itself only
after the exec() of the command on the server side had succeeded, so
that you wouldn't need a separate option to make sure the command was
launched successfully.  Unfortunately, the elegance of this design is
more than offset by the fact that it's completely and utterly impossible
to implement.  I apologize for the minute of your life you just wasted
reading this paragraph.)

Cheers,

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican