Re: Ash wildcard usability bug
On Thu, Oct 27, 2016, at 09:14, Kang-Che Sung wrote: > If you are arguing about usability, you should assume a case that you > are in an _interactive_ shell. Non-interactive environment is for > shell scripts, and for that portability and robustness will be more > important than what you called "usability". It was implied that I was in an interactive shell; apologies if you got the impression I was arguing for this in non-interactive shells. - Lauri -- http://www.fastmail.com - Or how I learned to stop worrying and love email again ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
On Wed, Oct 26, 2016 at 5:28 PM, Lauri Kasanen wrote: > On Wed, Oct 26, 2016, at 05:44, Kang-Che Sung wrote: >> I wonder why you can't implement an easy workaround using ls or >> something. >> >> filename="`ls *zip | head -n 1`" >> nc 10.0.0.1 12345 < "$filename" >> do_something_else < "$filename" >> >> Yeah. Just avoid the glob on the redirection and instead get the >> filename before that. Any difficulty? > > Because typing that takes longer? You're missing the point of an > usability feature. > > - Lauri If you are arguing about usability, you should assume a case that you are in an _interactive_ shell. Non-interactive environment is for shell scripts, and for that portability and robustness will be more important than what you called "usability". And for that portability includes compatibility across platforms and standards compliance (whenever possible). I think since POSIX has standardized this behavior, and other shells follow, there is not much point to argue with these further. At least not in BusyBox. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
On Wed, Oct 26, 2016, at 05:44, Kang-Che Sung wrote: > I wonder why you can't implement an easy workaround using ls or > something. > > filename="`ls *zip | head -n 1`" > nc 10.0.0.1 12345 < "$filename" > do_something_else < "$filename" > > Yeah. Just avoid the glob on the redirection and instead get the > filename before that. Any difficulty? Because typing that takes longer? You're missing the point of an usability feature. - Lauri -- http://www.fastmail.com - Choose from over 50 domains or use your own ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
* Kang-Che Sung [26.10.2016 10:00]: > filename="`ls *zip | head -n 1`" > nc 10.0.0.1 12345 < "$filename" > do_something_else < "$filename" > > Yeah. Just avoid the glob on the redirection and instead get the > filename before that. Any difficulty? better do (without pipes and cheating): for file in *zip; do test -f "$file" && action... done bye, bastian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
AW: Ash wildcard usability bug
> Von: Lauri Kasanen [mailto:cur...@operamail.com] > Gesendet: Dienstag, 25. Oktober 2016 19:25 > > > > On Mon, Oct 24, 2016, at 20:09, Denys Vlasenko wrote: > > > > Note that they allow to consistently never do globbing on the > > > > redirect word. > > > > > > > > To me it looks like the best course of action. > > > > > > Surely we all agree that it's terrible usability to not expand it? > > > > It may be terrible, but it's conforming to POSIX. ;-) > > > > But in earnest, I think in most cases it is more convenient to use Tab > > completion rather than *. > > Well, I did try to use tab completion: cat < *zip[TAB] > > Of course it doesn't work. In my case, I had many files sharing a > prefix, but only one ending in *zip, so typing that was several > times faster than letter- tab, oh more letters, tab, oh, more > letters, tab, more In this example, you could use the even shorter: cat *zip But I see your point - there are indeed cases where pathname expansion on redirections is utile, and since it's also conforming to POSIX for an interactive shell, I have no objection to it. -- Best regards, Dietmar manroland web systems GmbH -- Managing Director: Alexander Wassermann Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- VAT: DE281389840 Confidentiality note: This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
On Wed, Oct 26, 2016 at 1:24 AM, Lauri Kasanen wrote: > > Well, I did try to use tab completion: cat < *zip[TAB] > > Of course it doesn't work. In my case, I had many files sharing a > prefix, but only one ending in *zip, so typing that was several > times faster than letter- tab, oh more letters, tab, oh, more > letters, tab, more > I wonder why you can't implement an easy workaround using ls or something. filename="`ls *zip | head -n 1`" nc 10.0.0.1 12345 < "$filename" do_something_else < "$filename" Yeah. Just avoid the glob on the redirection and instead get the filename before that. Any difficulty? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
> > On Mon, Oct 24, 2016, at 20:09, Denys Vlasenko wrote: > > > Note that they allow to consistently never do globbing on the > > > redirect word. > > > > > > To me it looks like the best course of action. > > > > Surely we all agree that it's terrible usability to not expand it? > > It may be terrible, but it's conforming to POSIX. ;-) > > But in earnest, I think in most cases it is more convenient to use Tab > completion rather than *. Well, I did try to use tab completion: cat < *zip[TAB] Of course it doesn't work. In my case, I had many files sharing a prefix, but only one ending in *zip, so typing that was several times faster than letter- tab, oh more letters, tab, oh, more letters, tab, more - Lauri -- http://www.fastmail.com - mmm... Fastmail... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
AW: Ash wildcard usability bug
> Von: Lauri Kasanen [mailto:cur...@operamail.com] > Gesendet: Dienstag, 25. Oktober 2016 10:49 > > On Mon, Oct 24, 2016, at 20:09, Denys Vlasenko wrote: > > Note that they allow to consistently never do globbing > > on the redirect word. > > > > To me it looks like the best course of action. > > Surely we all agree that it's terrible usability to not expand it? It may be terrible, but it's conforming to POSIX. ;-) But in earnest, I think in most cases it is more convenient to use Tab completion rather than *. -- Best regards, Dietmar Schindler manroland web systems GmbH -- Managing Director: Alexander Wassermann Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- VAT: DE281389840 Confidentiality note: This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
On Mon, Oct 24, 2016, at 20:09, Denys Vlasenko wrote: > Note that they allow to consistently never do globbing > on the redirect word. > > To me it looks like the best course of action. Surely we all agree that it's terrible usability to not expand it? - Lauri -- http://www.fastmail.com - IMAP accessible web-mail ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
On Mon, Oct 24, 2016 at 8:20 AM, wrote: >> Von: Denys Vlasenko >> Gesendet: Montag, 24. Oktober 2016 01:31 >> ... >> >> On Tue, Oct 18, 2016 at 4:31 PM, Lauri Kasanen wrote: >> > The following fails in ash 1.24.1, probably also in git. Works in bash. >> >> but not in non-interactive bash called as sh! >> >> Interactive bash: works >> Interactive bash called as sh: works >> bash -c 'cat > sh -c 'cat > >> This is illogical. > > It may be illogical, but at least it's documented. > > www.gnu.org/software/bash/manual/bash.html#Bash-Startup-Files - "When invoked > as sh, Bash enters POSIX mode after the startup files are read." > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07 > - "Pathname expansion shall not be performed on the word by a > non-interactive shell; an interactive shell may perform it, but shall do so > only when the expansion would result in one word." Yes. Standards merely codified existing practice. Note that they allow to consistently never do globbing on the redirect word. To me it looks like the best course of action. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
AW: Ash wildcard usability bug
> Von: Denys Vlasenko > Gesendet: Montag, 24. Oktober 2016 01:31 > ... > > On Tue, Oct 18, 2016 at 4:31 PM, Lauri Kasanen wrote: > > The following fails in ash 1.24.1, probably also in git. Works in bash. > > but not in non-interactive bash called as sh! > > Interactive bash: works > Interactive bash called as sh: works > bash -c 'cat sh -c 'cat > This is illogical. It may be illogical, but at least it's documented. www.gnu.org/software/bash/manual/bash.html#Bash-Startup-Files - "When invoked as sh, Bash enters POSIX mode after the startup files are read." http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07 - "Pathname expansion shall not be performed on the word by a non-interactive shell; an interactive shell may perform it, but shall do so only when the expansion would result in one word." -- Best regards, Dietmar Schindler manroland web systems GmbH -- Managing Director: Alexander Wassermann Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No.: 26816 -- VAT: DE281389840 Confidentiality note: This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, then please delete this eMail. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
On Tue, Oct 18, 2016 at 4:31 PM, Lauri Kasanen wrote: > The following fails in ash 1.24.1, probably also in git. Works in bash. but not in non-interactive bash called as sh! Interactive bash: works Interactive bash called as sh: works bash -c 'cat http://lists.busybox.net/mailman/listinfo/busybox
Re: Ash wildcard usability bug
Lauri Kasanen wrote: >The following fails in ash 1.24.1, probably also in git. Works in bash. > >nc 10.0.0.1 1234 < *zip > >"sh: can't open *zip: no such file" > >Also applies to cat, etc. With only one matching file in the directory. Confirmed that it fails with latest git master. It also fails with latest dash. POSIX says for this case: Pathname expansion shall not be performed on the word by a non-interactive shell; an interactive shell may perform it, but shall do so only when the expansion would result in one word. which suggests that not performing the expansion is acceptable. The code (both in Busybox and dash) uses the symbol EXP_REDIR to cover this case but most occurrences are of the form /* TODO - EXP_REDIR */ So it looks as though somebody would need to do it... Ron ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Ash wildcard usability bug
Hi, The following fails in ash 1.24.1, probably also in git. Works in bash. nc 10.0.0.1 1234 < *zip "sh: can't open *zip: no such file" Also applies to cat, etc. With only one matching file in the directory. - Lauri -- http://www.fastmail.com - The way an email service should be ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
