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

[Nicolas Williams]

On Fri, Feb 01, 2002 at 08:07:06PM -0500, Dan Astoorian wrote:
> 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'.

This one almost is :)

> 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.

Do you have any wrappers that add -f? I think I can code wrappers to be
smart enough about this, so I'm not concerned.

> There is historical precedent for more -v's making output more verbose,

Yes.

> 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.

No, I'm making "-f -f" mean "like -f, but a bit later".

> 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.

I already said I wasn't going to use the long option name I'd originally
come up with, it's not even in the patch I submitted.

> 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 :-)

Sure. Have you any suggestions?

> 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.

I agree on principle. But there are exceptions to rules of thumb and I
think this is one of them. Have you understood the feature?

> (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

No, this does not guarantee that by the time ssh exits the X11 display
has been opened by the remote command or that the remote command has
exited. This is what I'm after.

I need to know that when "ssh -f -f -X user at host someX11app" exits it is
either because "someX11app" has opened the forwarded display or it
exited without opening the display (and if so, with what error code) or
that the remote shell couldn't find "someX11app."

People use "ssh -f ..." as an approximation of "ssh -f -f ..." for
launching X apps. Visual feedback tells them whether or not something
went wrong.

But suppose you're writing a GUI app so users can start X apps with a
click of a mouse. How do you check for errors in starting the remote
apps? If you use "ssh -f ..." you can't. And if you don't use -f you
never know when the remote app has opened the display, so you never know
when to stop paying attention to ssh's stderr and what not. But with
"ssh -f -f ...", if you're starting an X11 app, it's fire and forget -
when you get SIGCHLD and reap the ssh you'll know for sure if there was
an error or not (the only way you wouldn't is if the remote app has some
infinite loop bug).

> 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


Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.