zsh-users
 help / color / mirror / Atom feed
* detect pipe
@ 2021-01-27 16:45 Ray Andrews
  2021-01-27 23:59 ` Bart Schaefer
  0 siblings, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-27 16:45 UTC (permalink / raw)
  To: Zsh Users

I have a function that as used this test for piping quite reliably:

     if [ ! -t 0 ]; then

... but today it stopped working.  I thought I might have broken 
something in the function so tried backups and it would flicker in and 
out of effect, work one time and not the next.  Searching the web I see 
that apparently the above test is not 100% reliable. True?  If so, is 
there a better way?  This is probably not strictly a zsh problem but the 
randomness of it working intermittently suggests some time lag or delay 
or something. Perhaps the test needs time to think?  Someone might have 
a workaround even if this isn't zsh's fault.



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-27 16:45 detect pipe Ray Andrews
@ 2021-01-27 23:59 ` Bart Schaefer
  2021-01-28  4:57   ` Ray Andrews
  0 siblings, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-01-27 23:59 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Wed, Jan 27, 2021 at 8:45 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> I have a function that as used this test for piping quite reliably:
>
>      if [ ! -t 0 ]; then
>
> ... but today it stopped working.

[ -t 0 ] or [[ -t 0 ]] mean that the standard input is a terminal.
It's quite possible for standard input to be neither a terminal (so [[
! -t 0 ]] is true) nor a pipe.  For example, redirection from a file
or use of a here-document will both take the then-branch of "if [[ !
-t 0 ]]; then ... else ... fi".

> there a better way?  This is probably not strictly a zsh problem but the
> randomness of it working intermittently suggests some time lag or delay

A race condition would be unlikely to be a cause here.

[[ -p /dev/fd/0 ]] would be a more reliable test, because of the way
conditional expressions special case the prefix "/dev/fd/".


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-27 23:59 ` Bart Schaefer
@ 2021-01-28  4:57   ` Ray Andrews
  2021-01-28  6:16     ` Bart Schaefer
  2021-01-28 10:08     ` Vincent Lefevre
  0 siblings, 2 replies; 28+ messages in thread
From: Ray Andrews @ 2021-01-28  4:57 UTC (permalink / raw)
  To: zsh-users

On 2021-01-27 3:59 p.m., Bart Schaefer wrote:
> [[ -p /dev/fd/0 ]]
Nuts, using that it turns out that the issue is that my functions tend 
to be called via aliases:

     alias test2='noglob test1'

    test1 ()
    {
         if [[ -p /dev/fd/0 ]]; then
             echo "PIPES ARE AS BAD AS CIGARETTES"
             grep --color=always "$1"
         else
             echo "NO, THEY AREN'T"
             grep --color=always "$1" "$2"
         fi
    }


Testing it:

    $ . test; echo "Now is the time for all good men" | test1 'the time'
    PIPES ARE AS BAD AS CIGARETTES
    Now is the time for all good men

    $ . test; echo "Now is the time for all good men" | test2 'the time'
    NO, THEY AREN'T
    grep: : No such file or directory

    $ . test; test1 'the time' junk    # junk contains the same string
    NO, THEY AREN'T
    Now is the time for all good men

    $ . test; test2 'the time' junk
    NO, THEY AREN'T
    Now is the time for all good men

... so the pipe test is fooled by the alias. Strange tho that it used to 
work and still does *sometimes*.  Very flaky. Dunno why an alias would 
... well that's just it, I don't know.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28  4:57   ` Ray Andrews
@ 2021-01-28  6:16     ` Bart Schaefer
  2021-01-28 10:08     ` Vincent Lefevre
  1 sibling, 0 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-01-28  6:16 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Wed, Jan 27, 2021 at 8:57 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2021-01-27 3:59 p.m., Bart Schaefer wrote:
> > [[ -p /dev/fd/0 ]]
> Nuts, using that it turns out that the issue is that my functions tend
> to be called via aliases:

That makes no sense at all.  Have you tried doing your test with "set
-x" (setopt xtrace) in effect so that you get a trace of exactly
what's happening?


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28  4:57   ` Ray Andrews
  2021-01-28  6:16     ` Bart Schaefer
@ 2021-01-28 10:08     ` Vincent Lefevre
  2021-01-28 10:28       ` Vincent Lefevre
  1 sibling, 1 reply; 28+ messages in thread
From: Vincent Lefevre @ 2021-01-28 10:08 UTC (permalink / raw)
  To: zsh-users

On 2021-01-27 20:57:36 -0800, Ray Andrews wrote:
>    test1 ()
>    {
>         if [[ -p /dev/fd/0 ]]; then

The semicolon after ]] is invalid. I get an error

zsh: parse error near `then'

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28 10:08     ` Vincent Lefevre
@ 2021-01-28 10:28       ` Vincent Lefevre
  2021-01-28 15:05         ` Ray Andrews
  0 siblings, 1 reply; 28+ messages in thread
From: Vincent Lefevre @ 2021-01-28 10:28 UTC (permalink / raw)
  To: zsh-users

On 2021-01-28 11:08:58 +0100, Vincent Lefevre wrote:
> On 2021-01-27 20:57:36 -0800, Ray Andrews wrote:
> >    test1 ()
> >    {
> >         if [[ -p /dev/fd/0 ]]; then
> 
> The semicolon after ]] is invalid. I get an error
> 
> zsh: parse error near `then'

Actually the issue is nbsp characters in the posted code!

I can't reproduce the issue. Ray, is this due to the alias or to
the noglob? i.e. what do you get with the following?

  echo "Now is the time for all good men" | noglob test1 'the time'

I was wondering whether the noglob could introduce a small timing
difference where the LHS command would terminate earlier.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28 10:28       ` Vincent Lefevre
@ 2021-01-28 15:05         ` Ray Andrews
  2021-01-28 15:45           ` Ray Andrews
  0 siblings, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-28 15:05 UTC (permalink / raw)
  To: zsh-users

On 2021-01-28 2:28 a.m., Vincent Lefevre wrote:
>
>>>          if [[ -p /dev/fd/0 ]]; then
>> The semicolon after ]] is invalid. I get an error
>>
>> zsh: parse error near `then'
No error here.  How can that be?  Virgin shell also reports no error.  
This is with Roman's prebuilt core.  Besides, I thought the sem was 
compulsory, no?
>> Actually the issue is nbsp characters in the posted code!
?? Mind ... it was copied and pasted from an editor so yeah, an nbsp 
could be in there.  Rather rude!
>    echo "Now is the time for all good men" | noglob test1 'the time'
>
> I was wondering whether the noglob could introduce a small timing
> difference where the LHS command would terminate earlier.
>
I fired up the same test as last night and the results were the same.  I 
then removed the 'noglob' from the alias and everything worked fine.  I 
put the 'noglob' back and ... everything remained fine :-|   But this 
replicates the strangeness of the thing, it seems unpredictable which is 
why I smell the same issue -- some sort of microsecond delay of some 
sort such that the results would flicker as they have.  Bart mentions 
that piping involves simultaneous activity which sounds like a good 
place for a bad delay.

I'll run it with 'set -x' as Bart suggests once it starts to misbehave 
again.  I've always had a talent for breaking things. Anyway this is not 
zsh's problem I think.




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28 15:05         ` Ray Andrews
@ 2021-01-28 15:45           ` Ray Andrews
  2021-01-28 20:58             ` Bart Schaefer
  0 siblings, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-28 15:45 UTC (permalink / raw)
  To: zsh-users

On 2021-01-28 7:05 a.m., Ray Andrews wrote:

Delays of some sort are part of this almost for sure.  As it was, the 
test for the pipe was a hundred lines down in my function.  If I 
simplify the alias and move the pipe test  to the top of the function:

#alias g='tabs -4; noglob _g'
alias g='noglob _g'
function _g ()
{
local ppipe_flag=
[[ -p /dev/fd/0 ]] && ppipe_flag=1

... reliability increases to maybe 80%.  Still, if I pipe directly into  
' _g ', bypassing the alias, reliability is 100%.  As for test1 and 
test2 from last night, they are both 100% right now. Thursday's are 
lucky.    Funny thing, if  ' g '  works ten times, then breaks, once 
it's broke, it stays broke, I can run it ten more times and it won't fix 
itself.  Something changes in the OS I think.




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28 15:45           ` Ray Andrews
@ 2021-01-28 20:58             ` Bart Schaefer
  2021-01-28 20:59               ` Bart Schaefer
  2021-01-29  1:17               ` Ray Andrews
  0 siblings, 2 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-01-28 20:58 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Thu, Jan 28, 2021 at 7:45 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2021-01-28 7:05 a.m., Ray Andrews wrote:
>
> Delays of some sort are part of this almost for sure.
> Something changes in the OS I think.

Speaking of that, what OS are you using?

> #alias g='tabs -4; noglob _g'

That is guaranteed NOT to work.  With that alias in place, your pipe
is feeding into the "tabs" command, and then the _g function is run
with the regular shell standard input in place.  Aliases are
command-text-level replacements, so  given the above,

% echo something | g other

is the same as

% echo something | tabs -4; _g other

which (in case not already obvious) is just like

% echo something | tabs -4
% _g other

The only way that would ever report stdin as a pipe would be if it
appeared in a compound command context, something like one of

% echo something | { g other }
% echo something | ( g other }
% echo something | if g other; then ... fi
etc.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28 20:58             ` Bart Schaefer
@ 2021-01-28 20:59               ` Bart Schaefer
  2021-01-29  1:17               ` Ray Andrews
  1 sibling, 0 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-01-28 20:59 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Thu, Jan 28, 2021 at 12:58 PM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> % echo something | ( g other }

% echo something | ( g other )  # obviously


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-28 20:58             ` Bart Schaefer
  2021-01-28 20:59               ` Bart Schaefer
@ 2021-01-29  1:17               ` Ray Andrews
  2021-01-29  2:50                 ` Bart Schaefer
  1 sibling, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-29  1:17 UTC (permalink / raw)
  To: zsh-users

On 2021-01-28 12:58 p.m., Bart Schaefer wrote:
>
> Speaking of that, what OS are you using?
Debian stable.
>> #alias g='tabs -4; noglob _g'
> That is guaranteed NOT to work.  With that alias in place, your pipe
> is feeding into the "tabs" command, and then the _g function is run
> with the regular shell standard input in place.  Aliases are
> command-text-level replacements, so  given the above,
Nuts, that makes sense.  Thing is tho that it usually did work, so maybe 
the puzzle is why it *ever* worked.   Running exactly the same command 
I'd get 'hit hit hit miss miss' that sort of thing.  But memory tickles 
me.  Something about sourcing a file and then the alias only works on 
the next call ... something like that?
But I followed the wrong scent there, I removed it in the thought of 
speeding things up but your explanation is
rock solid at least in theory.  Another one of my wild goose chases.  
Tidbit: when I try 'tabs; noglob _g' it works.  The tab command fails 
for lack of an argument  and it seems the pipe then goes to '_g':


$ . test; echo "Now is the time for all good men" | test2 'the time'
PIPES ARE AS BAD AS CIGARETTES
Now is the time for all good men

$ . test; echo "Now is the time for all good men" | test2 'the time'
tabs: no tab-list given
NO, THEY AREN'T
grep: : No such file or directory




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-29  1:17               ` Ray Andrews
@ 2021-01-29  2:50                 ` Bart Schaefer
  2021-01-29  3:21                   ` Ray Andrews
  0 siblings, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-01-29  2:50 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Thu, Jan 28, 2021 at 5:17 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Debian stable.

Hm.  That doesn't explain anything, then; if you'd said "Cygwin", for
example, I'd have speculated that pipes were only simulated and then
it could make sense that having one get closed early would mean that
[[ -p ... ]] became false.

> Tidbit: when I try 'tabs; noglob _g' it works.  The tab command fails
> for lack of an argument  and it seems the pipe then goes to '_g':
>
> $ . test; echo "Now is the time for all good men" | test2 'the time'
> PIPES ARE AS BAD AS CIGARETTES
> Now is the time for all good men

Hang on, that's not going to work either.

If you're defining the alias "test2" inside the file "test", you can't
run it all together on one line like that.

% . =(echo "alias test2='cat -'"); echo this | test2
zsh: command not found: test2
% alias test2
test2='cat -'

NOW the test2 alias exists, so if I repeat that:

% . =(echo "alias test2='cat -'"); echo this | test2
this

So the FIRST time you tried ". test; ...", if you DID NOT get an
error, there was some previous thing named "test2" lying around, which
probably behaved differently.

You can't define an alias and use it both in the same single line command.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-29  2:50                 ` Bart Schaefer
@ 2021-01-29  3:21                   ` Ray Andrews
  2021-01-30  0:29                     ` Bart Schaefer
  0 siblings, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-29  3:21 UTC (permalink / raw)
  To: zsh-users

On 2021-01-28 6:50 p.m., Bart Schaefer wrote:

> NOW the test2 alias exists, so if I repeat that:
> So the FIRST time you tried ". test; ...", if you DID NOT get an
> error, there was some previous thing named "test2" lying around, which
> probably behaved differently.
>
> You can't define an alias and use it both in the same single line command.
That's what I was trying to remember -- that sort of gotcha.  Yup, the 
define and use thing.
Still it is all logical -- previous editions of the alias still lurking 
around and only next time
being changed so I'm lead down the garden path.  I'll not forget that 
again.  Sorry to waste
everyone's time.



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-29  3:21                   ` Ray Andrews
@ 2021-01-30  0:29                     ` Bart Schaefer
  2021-01-30 14:26                       ` Ray Andrews
  0 siblings, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-01-30  0:29 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Thu, Jan 28, 2021 at 7:22 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Sorry to waste everyone's time.

Not necessarily a waste.

A couple of more words on this, particularly on the theme of "tabs -4".

"tabs" adjusts the terminal, and pretty much by definition only for
output, so you should be able to get away with

# Only run "tabs" on terminal stdout
# Close stdin to avoid stealing input
[[ -t 1 ]] && tabs -4 <&-

The next thing to note is that you can use "anonymous" functions in an
alias definition:

alias g='function {
  [[ -t 1 ]] && tabs -4 <&-
  grep --color=always "$@"
}'

This works because words following the closing brace of an anonymous
function become its argument list.  Simpler example:

% alias q='function { print -rl -- "$@" }'
% q a b c
a
b
c
%

I'd also point out that by using "$@" instead of "$1" "$2" in "g", you
never pass an empty string as the filename to grep.  That means you
don't have to care whether standard input is a pipe; it will read
standard input if there is one argument, and read from $2 (and any
subsequent file names) if there are 2 or more arguments.  The
difference from your original definition is that you don't get "grep:
: No such file or directory" if you pass 1 argument when the standard
input is NOT a pipe.

The last note is that this inlined-function trick does NOT work with
"noglob".  You CANNOT write e.g.

noglob function { print -rl -- "$@" } a* *b

So if you want to introduce noglob, you have to use a real function.
You can still do everything else I mentioned.

_g() {
  [[ -t 1 ]] && tabs -4 <&-
  grep --color=always "$@"
}
alias g='noglob _g'


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-30  0:29                     ` Bart Schaefer
@ 2021-01-30 14:26                       ` Ray Andrews
  2021-01-30 19:00                         ` Bart Schaefer
  0 siblings, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-30 14:26 UTC (permalink / raw)
  To: zsh-users

On 2021-01-29 4:29 p.m., Bart Schaefer wrote:
> # Close stdin to avoid stealing input
> [[ -t 1 ]] && tabs -4 <&-
>
>
Cool stuff Bart.  Would you please elaborate on 'Close stdin'?




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-30 14:26                       ` Ray Andrews
@ 2021-01-30 19:00                         ` Bart Schaefer
  2021-01-30 19:19                           ` Ray Andrews
  2021-02-14 17:31                           ` Vincent Lefevre
  0 siblings, 2 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-01-30 19:00 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Sat, Jan 30, 2021 at 6:27 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Cool stuff Bart.  Would you please elaborate on 'Close stdin'?

ubuntu% ls /dev/fd/0
/dev/fd/0
ubuntu% ls /dev/fd/0 <&-
ls: cannot access '/dev/fd/0': No such file or directory

File descriptor zero, the standard input, has been closed; it
literally does not exist for "ls" (in this example).  If it's closed,
it's not possible to read from it:

ubuntu% cat <&-
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor

Most commands will ignore a closed stdin and behave similarly to
reading from /dev/null.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-30 19:00                         ` Bart Schaefer
@ 2021-01-30 19:19                           ` Ray Andrews
  2021-01-31 19:12                             ` Ray Andrews
  2021-02-14 17:31                           ` Vincent Lefevre
  1 sibling, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-30 19:19 UTC (permalink / raw)
  To: zsh-users

On 2021-01-30 11:00 a.m., Bart Schaefer wrote:
> ubuntu% ls /dev/fd/0
> /dev/fd/0
> ubuntu% ls /dev/fd/0 <&-
> ls: cannot access '/dev/fd/0': No such file or directory
>
What would be the practical use of that?



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-30 19:19                           ` Ray Andrews
@ 2021-01-31 19:12                             ` Ray Andrews
  2021-01-31 21:28                               ` Bart Schaefer
  0 siblings, 1 reply; 28+ messages in thread
From: Ray Andrews @ 2021-01-31 19:12 UTC (permalink / raw)
  To: zsh-users

On 2021-01-30 11:19 a.m., Ray Andrews wrote:
> On 2021-01-30 11:00 a.m., Bart Schaefer wrote:
>> ubuntu% ls /dev/fd/0
>> /dev/fd/0
>> ubuntu% ls /dev/fd/0 <&-
>> ls: cannot access '/dev/fd/0': No such file or directory
>>
> What would be the practical use of that?
Because it keeps 'tabs' from being fed arguments that it doesn't want, 
and zsh is then smart enough to sent those args on to the next  command :-)




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-31 19:12                             ` Ray Andrews
@ 2021-01-31 21:28                               ` Bart Schaefer
  0 siblings, 0 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-01-31 21:28 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Sun, Jan 31, 2021 at 11:12 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Because it keeps 'tabs' from being fed arguments that it doesn't want,
> and zsh is then smart enough to sent those args on to the next  command :-)

Well, not arguments, but standard input from the pipe (or wherever).
This doesn't really have anything to do with zsh, it's how file
descriptors work at the OS level.  Zsh is just providing you a tool to
make use of that.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-01-30 19:00                         ` Bart Schaefer
  2021-01-30 19:19                           ` Ray Andrews
@ 2021-02-14 17:31                           ` Vincent Lefevre
  2021-02-14 19:33                             ` Bart Schaefer
  1 sibling, 1 reply; 28+ messages in thread
From: Vincent Lefevre @ 2021-02-14 17:31 UTC (permalink / raw)
  To: zsh-users

On 2021-01-30 11:00:15 -0800, Bart Schaefer wrote:
> On Sat, Jan 30, 2021 at 6:27 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
> >
> > Cool stuff Bart.  Would you please elaborate on 'Close stdin'?
> 
> ubuntu% ls /dev/fd/0
> /dev/fd/0
> ubuntu% ls /dev/fd/0 <&-
> ls: cannot access '/dev/fd/0': No such file or directory
> 
> File descriptor zero, the standard input, has been closed; it
> literally does not exist for "ls" (in this example).  If it's closed,
> it's not possible to read from it:
> 
> ubuntu% cat <&-
> cat: -: Bad file descriptor
> cat: closing standard input: Bad file descriptor
> 
> Most commands will ignore a closed stdin and behave similarly to
> reading from /dev/null.

Closing stdin is a bad idea, as this can break stdout redirection,
and this may be out of control of the commands. See

  https://sourceware.org/bugzilla/show_bug.cgi?id=682

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 17:31                           ` Vincent Lefevre
@ 2021-02-14 19:33                             ` Bart Schaefer
  2021-02-14 20:33                               ` Ray Andrews
  2021-02-14 21:19                               ` Vincent Lefevre
  0 siblings, 2 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-02-14 19:33 UTC (permalink / raw)
  To: Zsh Users

On Sun, Feb 14, 2021 at 9:31 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> Closing stdin is a bad idea, as this can break stdout redirection,
> and this may be out of control of the commands. See
>
>   https://sourceware.org/bugzilla/show_bug.cgi?id=682

IMO that's just silly.  If stdin/stdout were never supposed to be
closed, why has the standard shell had <&- and >&- for its entire
existence?  Why wouldn't those be syntax errors when a file descriptor
number is not provided if you're never supposed to use them?


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 19:33                             ` Bart Schaefer
@ 2021-02-14 20:33                               ` Ray Andrews
  2021-02-14 21:20                                 ` Bart Schaefer
  2021-02-14 21:24                                 ` Vincent Lefevre
  2021-02-14 21:19                               ` Vincent Lefevre
  1 sibling, 2 replies; 28+ messages in thread
From: Ray Andrews @ 2021-02-14 20:33 UTC (permalink / raw)
  To: zsh-users

On 2021-02-14 11:33 a.m., Bart Schaefer wrote:
> On Sun, Feb 14, 2021 at 9:31 AM Vincent Lefevre <vincent@vinc17.net> wrote:
>> Closing stdin is a bad idea, as this can break stdout redirection,
>> and this may be out of control of the commands. See
>>
>>    https://sourceware.org/bugzilla/show_bug.cgi?id=682
> IMO that's just silly.  If stdin/stdout were never supposed to be
> closed, why has the standard shell had <&- and >&- for its entire
> existence?  Why wouldn't those be syntax errors when a file descriptor
> number is not provided if you're never supposed to use them?
>
If it is closed, where does input go?  Queued up or vanish?



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 19:33                             ` Bart Schaefer
  2021-02-14 20:33                               ` Ray Andrews
@ 2021-02-14 21:19                               ` Vincent Lefevre
  2021-02-14 21:24                                 ` Bart Schaefer
  2021-02-14 21:38                                 ` Bart Schaefer
  1 sibling, 2 replies; 28+ messages in thread
From: Vincent Lefevre @ 2021-02-14 21:19 UTC (permalink / raw)
  To: zsh-users

On 2021-02-14 11:33:11 -0800, Bart Schaefer wrote:
> On Sun, Feb 14, 2021 at 9:31 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > Closing stdin is a bad idea, as this can break stdout redirection,
> > and this may be out of control of the commands. See
> >
> >   https://sourceware.org/bugzilla/show_bug.cgi?id=682
> 
> IMO that's just silly.  If stdin/stdout were never supposed to be
> closed, why has the standard shell had <&- and >&- for its entire
> existence?  Why wouldn't those be syntax errors when a file descriptor
> number is not provided if you're never supposed to use them?

To make the rule the same for all file descriptors and all redirection
type?

Note also that something like

  { cat < file } <&-

is OK (the <&- is useless here, but there might be cases where this
could be useful).

In any case, it is a bad idea to use a closed standard fd, unless
you know that this is supported by the command. For instance, note
the difference with "cat" from the GNU coreutils 8.32:

$ echo foo > file
$ cat <&- file -
foo
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
$ cat < /dev/null file -
foo
$ 

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 20:33                               ` Ray Andrews
@ 2021-02-14 21:20                                 ` Bart Schaefer
  2021-02-14 22:25                                   ` Ray Andrews
  2021-02-14 21:24                                 ` Vincent Lefevre
  1 sibling, 1 reply; 28+ messages in thread
From: Bart Schaefer @ 2021-02-14 21:20 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Sun, Feb 14, 2021 at 12:33 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> If it is closed, where does input go?  Queued up or vanish?

File descriptors can be shared among processes.  Typically for example
the parent shell and any of its children will all have the same
standard input, unless there has been a redirection, including
creating a pipeline.

In the case of a pipeline, if ALL the processes that share a
descriptor have closed it, then the writer of the pipeline will get a
SIGPIPE signal.  The "input" (in this case, the output of the process
upstream in the pipeline) is neither queued nor vanishes; the attempt
to write fails and it's up to the writing process to decide how to
react to that, the default being for it to exit.

In the case of a file, the only affected process is the reader, which
gets "invalid file descriptor" if it attempts to read from stdin.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 21:19                               ` Vincent Lefevre
@ 2021-02-14 21:24                                 ` Bart Schaefer
  2021-02-14 21:38                                 ` Bart Schaefer
  1 sibling, 0 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-02-14 21:24 UTC (permalink / raw)
  To: Zsh Users

On Sun, Feb 14, 2021 at 1:19 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> In any case, it is a bad idea to use a closed standard fd, unless
> you know that this is supported by the command.

OK, suppose I do know it's supported by the command.  The proposed
POSIX change appears to me to mean that I can't cause the command to
receive a closed standard input, because the OS might reopen it to an
undefined location during fork/exec.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 20:33                               ` Ray Andrews
  2021-02-14 21:20                                 ` Bart Schaefer
@ 2021-02-14 21:24                                 ` Vincent Lefevre
  1 sibling, 0 replies; 28+ messages in thread
From: Vincent Lefevre @ 2021-02-14 21:24 UTC (permalink / raw)
  To: zsh-users

On 2021-02-14 12:33:35 -0800, Ray Andrews wrote:
> On 2021-02-14 11:33 a.m., Bart Schaefer wrote:
> > On Sun, Feb 14, 2021 at 9:31 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> > > Closing stdin is a bad idea, as this can break stdout redirection,
> > > and this may be out of control of the commands. See
> > > 
> > >    https://sourceware.org/bugzilla/show_bug.cgi?id=682
> > IMO that's just silly.  If stdin/stdout were never supposed to be
> > closed, why has the standard shell had <&- and >&- for its entire
> > existence?  Why wouldn't those be syntax errors when a file descriptor
> > number is not provided if you're never supposed to use them?
> > 
> If it is closed, where does input go?  Queued up or vanish?

I don't see any difference with a command, like "true", that doesn't
read anything.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 21:19                               ` Vincent Lefevre
  2021-02-14 21:24                                 ` Bart Schaefer
@ 2021-02-14 21:38                                 ` Bart Schaefer
  1 sibling, 0 replies; 28+ messages in thread
From: Bart Schaefer @ 2021-02-14 21:38 UTC (permalink / raw)
  To: Zsh Users

On Sun, Feb 14, 2021 at 1:19 PM Vincent Lefevre <vincent@vinc17.net> wrote:
>
> Note also that something like
>
>   { cat < file } <&-
>
> is OK (the <&- is useless here, but there might be cases where this
> could be useful).

I suppose

 ... | { exec <&- ; ... }

is useful for causing the upstream pipeline to get SIGPIPE and exit,
without waiting for the rest of the shell construct to finish.  Still,
that means the (previously) defined behavior is that anything spawned
by the rest of that construct has its stdin closed, so it still would
make more sense to require (syntactically enforce) { exec </dev/null }
here, if that was really the intent.


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: detect pipe
  2021-02-14 21:20                                 ` Bart Schaefer
@ 2021-02-14 22:25                                   ` Ray Andrews
  0 siblings, 0 replies; 28+ messages in thread
From: Ray Andrews @ 2021-02-14 22:25 UTC (permalink / raw)
  To: zsh-users

On 2021-02-14 1:20 p.m., Bart Schaefer wrote:
> upstream in the pipeline) is neither queued nor vanishes; the attempt
> to write fails and it's up to the writing process to decide how to
> react to that, the default being for it to exit.
Pretty close to vanishes tho.  I just mean there's no buffer or 
something that is going to dump out somewhere else.  Sounds logical 
that, as you say, it's just a failed write.


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-02-14 22:25 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-27 16:45 detect pipe Ray Andrews
2021-01-27 23:59 ` Bart Schaefer
2021-01-28  4:57   ` Ray Andrews
2021-01-28  6:16     ` Bart Schaefer
2021-01-28 10:08     ` Vincent Lefevre
2021-01-28 10:28       ` Vincent Lefevre
2021-01-28 15:05         ` Ray Andrews
2021-01-28 15:45           ` Ray Andrews
2021-01-28 20:58             ` Bart Schaefer
2021-01-28 20:59               ` Bart Schaefer
2021-01-29  1:17               ` Ray Andrews
2021-01-29  2:50                 ` Bart Schaefer
2021-01-29  3:21                   ` Ray Andrews
2021-01-30  0:29                     ` Bart Schaefer
2021-01-30 14:26                       ` Ray Andrews
2021-01-30 19:00                         ` Bart Schaefer
2021-01-30 19:19                           ` Ray Andrews
2021-01-31 19:12                             ` Ray Andrews
2021-01-31 21:28                               ` Bart Schaefer
2021-02-14 17:31                           ` Vincent Lefevre
2021-02-14 19:33                             ` Bart Schaefer
2021-02-14 20:33                               ` Ray Andrews
2021-02-14 21:20                                 ` Bart Schaefer
2021-02-14 22:25                                   ` Ray Andrews
2021-02-14 21:24                                 ` Vincent Lefevre
2021-02-14 21:19                               ` Vincent Lefevre
2021-02-14 21:24                                 ` Bart Schaefer
2021-02-14 21:38                                 ` Bart Schaefer

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git