Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14502

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

Show key headers only | View raw

2018-08-15 8:44 GMT-04:00 Greg Wooledge <wooledg@eeg.ccf.org>:

> 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 $* or $@ expansion.
> >
> > That is plainly INCORRECT, Greg.
>
> You are incorrect.


I am always incorrect, I like to be so.
But  we are discussing an issue, not my personal problems.


> > > It breaks in all kinds of ways in more than one shell.
> >
> > That several shells do different things is a bug on those shells, not
> bash.
>
> Agreed.


Excellent, we agree.


> And the fact that IN REAL LIFE, THOSE SHELLS EXIST AND HAVE
> THOSE BUGS, which are triggered by incorrect code


No, sorry, but bugs are triggered by perfectly good code, that's why they
are called bugs.


> , is a reason to write
> code correctly so as not to trigger those bugs.
>

Writing code to *work around* bugs is *not* the correct solution.
It is only a way to *perpetuate* those bugs.
The correct solution is to resolve the bugs.

But this is just a smoke curtain. There are no bugs about $@ and $* in Bash.

Or maybe you're one of those people who doesn't care about reality.
>

Sometimes I don't , most of the time when I sleep, sometimes when I day
dream.


> > > Just don't do it, and these problems go away.
> >
> > If I want the split+glob to take effect I can do:
> >
> >    echo $*
> >
> >
> > There is nothing wrong with that (don't claim that it change in different
> > shells, that is a different issue than using split+glob in bash, go back
> to
> > the point above about other shells if you wish).
>
> There is absolutely definitely positively 100% certainly something wrong
> with that.
>

Ah, yes, that's correct, thanks, I should have used printf, not echo.
But you corrected it, thanks again.

Let's break your script, shall we?
>
> Here's your script, except I'm going to represent it as a function.  Doing
> it as a script would have the same effect.
>
> glob() {
>     # "Return" (write to stdout, one per line) the expansions of all
>     # arguments as globs against the current working directory.
>     printf %s\\n $*
> }
>
> Will you at least agree that this is your intent,


No, that is *not* my intent.
You can not implement a glob function when *both: split and glob* are in
effect.

If you want a glob function, stop the split, set IFS to null:

    $ cat script
    #!/bin/bash
    glob() ( IFS=; printf %s\\n $* )
    glob '*Web Service*'

    $ ./script
    Epic Web Service - PatientLookup.pdf


and a fair
> representation of your proposed solution?  I'll take that as a "yes".
>

No it is not a fair representation of anything I said.
Only of a twist that you want to present here.

So now, you can pass SOME globs to it (properly quoted), and it will
> appear to work for those globs:
>

But it will fail to work on the next example as you want to demonstrate,
therefore you have not coded correctly to workaround the shells bugs
(your own words).

Some of us care about reality.
>

Yes, when I am awake.

Other languages have no problem with this.  Tcl,

(...)

But we are in bash, are we not?


Now, you tried to implement Tcl's [glob] in bash, but you did it naively
> and the naive version does not work.  You took a shortcut.  That shortcut
> falls off a cliff.
>

No, *you* did. You implemented a flawed glob function.


> I'll leave the non-broken implementation as an exercise for the reader.
>

You are not able to do it?


> Now, back to the original points:
>
> 1) Certain shells have bugs in them.  These shells are in widespread use
>    on real systems in real life.
>
> 2) One of those shells is bash, which makes it relevant to bug-bash.
>
> 3) Some of those bugs involve the unquoted expansions of $* and $@.
>

Not in bash.


> 4) Even in the ABSENCE of such bugs, the use of an unquoted $* or $@
>    expansion does not actually solve the problems you claim it solves.
>

I claimed nothing. I presented a valid use. Don't put words in my mouth.


> 5) Therefore, for TWO reasons, you should not use unquoted $* or $@
>    in your shell scripts.
>
>    Reason 1: it doesn't solve the problem.
>    Reason 2: it sometimes breaks even worse due to shell bugs.
>

There is no therefore if the premises are wrong.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: Assignment of $* to a var removes spaces on unset IFS. Bize Ma <binaryzebra@gmail.com> - 2018-08-15 11:54 -0400

csiph-web