Hi.  Thanks for your attention to detail and encouragement and
clarity.  I got around to looking at this.

tl;dr:

  I think in fact the patch is working as designed but your particular
  test scenario is equivalent to "screen screen --invalid-argument",
  which has a separate (and more fundamental) lost-error bug.

Let me expand on that.  This is all quite confusing.  I hope you will
spot if I have got something wrong.

You report:

   $ screen screen ../t.sh {0..999}
   [screen is terminating]
   $ echo $?
   0

That is indeed the behaviour I see (in all cases, I'm using your
salsa/debian-bug-1000138 branch).  I agree that this is not correct
overall behaviour.  (But I think the behaviour without my patch is
worse.)

I also observe:

  $ screen ../t.sh {0..999}
  <screen clears>
  1000
  <5 second pause>
  [screen is terminating]
  $ echo $?
  0

  $ screen
  <screen clears, intro message, press Return>
  $ screen ../t.sh {0..999}
  Argument count or length limit exceeded
  $ echo $?
  1
  $ ^D
  [screen is terminating]
  $ echo $?
  0

I think those are correct.  Well, strictly: the first is correct, and
the second is tolerable.

And:

  $ screen false
  <screen clears, and then instantly:>
  [screen is terminating]
  $ echo $?
  0

I think there is a strong argument that this last one is wrong.  But
it's not entirely clear what the semantics ought to be in the general
case.  Should a terminating session convey the exit status of the last
window to the outer environment, and thus to all attached clients ?

My patch changes the behaviour of your case
    screen screen ../t.sh {0..999}
from
  silently forgets all but the first 62 arguments
  processes the first 62
  discarding any the final error messages the and exit status
to
  immediately quit "successfully" having done nothing

I think this is an improvement.  Also "screen screen wombat" is a
funny thing to run, since one can start a screen containing only a
session running "wombat" with "screen wombat".


Indeed,
  screen screen --this-is-not-a-screen-argument
also just clears the screen and exits claiming success.

What this demonstrates is that "screen anything" has an inherent
tendency to lose errors from "anything".

When "anything" is screen itself, I still think it it is better for it
to do nothing and try to complain, than for it to pass only some of
its arguments and claim that everything is fine.  Even if it so
happens that here, the complaints are themselves being lost.


So I think you should probably ship my patch.

Users who are afflicted by a mysterious failure to do anything when
they run
  screen screen program thing with many many arguments
will at least know that something funny is going on and if they resort
to
  screen
  screen program thing with many many arguments
they will see the message.  Hopefully will think of doing that, or
simply be discouraged from trusting screen so much - that's not great,
but it's better than gaslighting the user.


Out of interest I did this

   $ ttyrec
   $ screen screen ../t.sh {0..999}
   <screen clears>
   [screen is terminating]
   $ ^D
   $ ipbt ttyrecord
   <press "o" then use "space" and "b" to go forwards and backwards">

and you can see that the error message is in there - it just flashes
up too briefly to see.  (ipbt is in the package its-playback-time)


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Reply via email to