Re: Unexpected delay in using arguments.

Bize Ma wrote: > > but just the same it is almost always possible > > to refactor a program into a different algorithm that avoids the need > > to enumerate so many arguments in memory. > > As you say: "almost". I still believe that to be true. Since you haven't shared what the actual task is th

Re: Assignment of $* to a var removes spaces on unset IFS.

This reply was sent to me without Cc-ing the list. I have added the Cc. On Tue, Aug 14, 2018 at 11:39:20PM -0400, Bize Ma wrote: > On Tue, 14 Aug 2018 12:34:31, Greg Wooledge said: > > > I will also repeat, once more, my advice that one should NEVER write > > a script containing an unquoted $* o

Re: Assignment of $* to a var removes spaces on unset IFS.

On 15.8. 15:44, Greg Wooledge wrote: glob() { # "Return" (write to stdout, one per line) the expansions of all # arguments as globs against the current working directory. printf %s\\n $* } But... but... but... the PREVIOUS glob worked! Why didn't this one work? I'm sure you kno

Re: Rational Range Interpretation for bash-5.0?

On 6.8. 23:07, Chet Ramey wrote: Hi. I am considering making bash glob expansion implement rational range interpretation starting with bash-5.0 -- basically making globasciiranges the default. It looks like glibc is going to do this for version 2.28 (at least for a-z, A-Z, and 0-9), and other GNU

Re: Unexpected delay in using arguments.

On 8/15/18 3:36 AM, Bob Proulx wrote: > It does look like bash can be more efficient with argument handling. > Since, for example, dash does it. Yes, it just needs new primitives to do it. The existing code for managing the saved positional parameters has been in bash since the pre-1.0 days and i

Re: Assignment of $* to a var removes spaces on unset IFS.

On 8/13/18 10:52 PM, Bize Ma wrote: >  > This is a bug in bash and it should be fixed, not excused. > > To which I agree. After a year, nothing else have been said about it. > > It seems about time to get it solved. Or say that it won't be. It's fixed in the current development versions, and th

Re: Assignment of $* to a var removes spaces on unset IFS.

On 8/14/18 8:34 AM, Greg Wooledge wrote: > On Mon, Aug 13, 2018 at 09:36:23PM -0400, Bize Ma wrote: >> Note that 4.4.19 is newer than what is available in >> https://www.gnu.org/software/bash/ > > The current patch level of bash can be obtained by downloading the most > recent tarball from

Re: "sh -a" sets the POSIXLY_CORRECT *environment* variable

On 8/14/18 11:50 AM, Stephane Chazelas wrote: > Hi, > > This is from > https://unix.stackexchange.com/questions/462333/why-does-a-in-bin-sh-a-affect-sed-and-set-a-doesnt > (original investigation by Mark Plotnick) > > Though not documented, enabling the POSIX mode in bash whether > with > > - ba

Re: Unexpected delay in using arguments.

2018-08-15 3:36 GMT-04:00 Bob Proulx : > Bize Ma wrote: > > I still believe that to be true. You are entitled to have an opinion, even if incorrect. > Since you haven't shared what the > actual task is there is no way for us to propose any counter example > improvements. So "almost" is as f

Re: "sh -a" sets the POSIXLY_CORRECT *environment* variable

On 8/15/18 11:05 AM, Chet Ramey wrote: >> causes it to set the value of the $POSIXLY_CORRECT shell >> variable to "y" (if it was not already set) > > Yes. This behavior dates from early 1997. It was put in on request so users > could get a posix environment from the shell, since GNU utilities > u

Re: Assignment of $* to a var removes spaces on unset IFS.

2018-08-15 8:44 GMT-04:00 Greg Wooledge : > This reply was sent to me without Cc-ing the list. I have added the Cc. > > On Tue, Aug 14, 2018 at 11:39:20PM -0400, Bize Ma wrote: > > On Tue, 14 Aug 2018 12:34:31, Greg Wooledge said: > > > > > I will also repeat, once more, my advice that one should

Re: "sh -a" sets the POSIXLY_CORRECT *environment* variable

2018-08-15 11:05:06 -0400, Chet Ramey: > On 8/14/18 11:50 AM, Stephane Chazelas wrote: > > Hi, > > > > This is from > > https://unix.stackexchange.com/questions/462333/why-does-a-in-bin-sh-a-affect-sed-and-set-a-doesnt > > (original investigation by Mark Plotnick) > > > > Though not documented, e