execlineb -S does not stop the command from running
Hi there, First of all, thanks for this fine and useful software on skaware. I'm using execline v2.5.0.0 (and 7ce423). I've tried to use the -S1 option to stop the command from running when not given any arguments. `execline` does indeed exits when not given arguments, and displays the error `execlineb: warning: too few arguments: expecting at least 1 but got 0` but the first command gets run. ``` $ execlineb -S1 -c 'echo wrong' execlineb: warning: too few arguments: expecting at least 1 but got 0 wrong ``` I've found the commit that introduces the error: ``` $ git bisect good 0294fb779bb603046da8ef1755d227553e93a881 is the first bad commit ``` However, that commit does not change execlineb and i'm lost at the codebase. What could have introduced the error?
Little correction on fdmove doc
I've found the command intuitive but the documentation confused me a little bit. So here's a patch. >From bb4dbf267857737ad88240d2ad9cead9b3c3481f Mon Sep 17 00:00:00 2001 From: Joshua Haase Date: Sun, 29 Jul 2018 04:44:57 -0500 Subject: [PATCH] fdmove documentation have fd backwards. --- doc/fdmove.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/fdmove.html b/doc/fdmove.html index 39bdb2b..c56787a 100644 --- a/doc/fdmove.html +++ b/doc/fdmove.html @@ -26,7 +26,7 @@ executes a program. Interface - fdmove [ -c ] fdto fdfrom prog... + fdmove [ -c ] fdfrom fdto prog... -- 2.17.1
Re: execlineb -S does not stop the command from running
`execline` does indeed exits when not given arguments, and displays the
error `execlineb: warning: too few arguments: expecting at least 1 but
got 0` but the first command gets run.
```
$ execlineb -S1 -c 'echo wrong'
execlineb: warning: too few arguments: expecting at least 1 but got 0
wrong
```
It's not an error, it's actually a bugfix. As you can see, the message
is a "warning", not a "fatal", which means it does not stop the
program from running. It has always been intended this way.
If you want to enforce a minimal number of arguments and exit if
that number is not reached, you have to do it from inside the script
with something like "if { test $# -ge 1 }".
That said, it's probably useful functionality for the execlineb
binary to have, so I'll consider having a switch implementing it
for a future version.
--
Laurent
Re: Little correction on fdmove doc
I've found the command intuitive but the documentation confused me a little bit. So here's a patch. ISTR you actually submitted the same thing a few months ago and I did not react. Sorry, I should have replied sooner. The documentation is correct and I won't apply the patch. But it's not your fault : you are right that it is a confusing matter. The confusion comes from a commonly wrong intuition of what a file descriptor is. When you "move file descriptors" (typically via dup2(), which fdmove is implemented over), the move goes in the opposite direction from what we intuitively think, because we tend to see the numbers as fixed and the data flows as changing - but the opposite is happening: the data flow does not change, the numbering does. If you send a mail to "Alice" and it ultimately arrives to "Bob", then you get the impression that "Alice" and "Bob" are two separate entities and that your mail went *from Alice to Bob*. But that's not what's happening with file descriptors. What really happened is that Bob changed their name *from Bob to Alice*, and when you send mail to Alice, it reaches the correct recipient that your mind still identifies as Bob. (Please don't deadname file descriptors, or people. It's rude.) So when you do "fdmove 2 1", the data you send as what you still perceive as stderr will now be sent to what you still perceive as stdout, so you think fdfrom is 2 and fdto is 1. But the reality is that your perception is wrong - what happened is that stdout just changed its numbering *from 1 to 2*, so it's now called stderr. You now have the responsibility to untangle the confusion among your friends and co-workers when it arises. :) -- Laurent
Re: execlineb -S does not stop the command from running
On Sun, Jul 29, 2018, at 08:50, Laurent Bercot wrote:
> >`execline` does indeed exits when not given arguments, and displays the
> >error `execlineb: warning: too few arguments: expecting at least 1 but
> >got 0` but the first command gets run.
> >
> >```
> >$ execlineb -S1 -c 'echo wrong'
> >execlineb: warning: too few arguments: expecting at least 1 but got 0
> >wrong
> >```
>
> It's not an error, it's actually a bugfix. As you can see, the message
> is a "warning", not a "fatal", which means it does not stop the
> program from running. It has always been intended this way.
> If you want to enforce a minimal number of arguments and exit if
> that number is not reached, you have to do it from inside the script
> with something like "if { test $# -ge 1 }".
>
> That said, it's probably useful functionality for the execlineb
> binary to have, so I'll consider having a switch implementing it
> for a future version.
That switch already exists :). Running execlineb with -W gets the desired
result:
$ execlineb -WS1 -c 'echo wrong'
execlineb: fatal: too few arguments: expecting at least 1 but got 0
I would think this would be equivalent:
$ EXECLINE_STRICT=2 execlineb -S1 -c 'echo wrong'
however, it reverts back to showing a warning.
Re: execlineb -S does not stop the command from running
Jesse Young (2018-07-29 12:19): |> >$ execlineb -S1 -c 'echo wrong' |> >execlineb: warning: too few arguments: expecting at least 1 but got 0 |> >wrong |> >``` |> |> It's not an error, it's actually a bugfix. As you can see, the message |> is a "warning", not a "fatal", which means it does not stop the |> program from running. It has always been intended this way. Oh, I see the usefulness of this for debbuging until right and then using strict when the script is ready. | That switch already exists :). Running execlineb with -W gets the desired result: | $ execlineb -WS1 -c 'echo wrong' | execlineb: fatal: too few arguments: expecting at least 1 but got Thanks! This does what what I want. | I would think this would be equivalent: | $ EXECLINE_STRICT=2 execlineb -S1 -c 'echo wrong' | however, it reverts back to showing a warning. Are the command line option taking precendence? The EXECLINE_STRICT option is not set explicitly on the command line however.
