Re:Bash $* and $@ (2017)
by Godel_unicode on Sunday January 12, 2020 @09:56PM
(#22031476)
Just because they write crappy Python doesn't mean they'd write good shell scripts. For me it indicates the opposite.
Re:Bash $* and $@ (2017)
by samtheprogram on Monday January 13, 2020 @12:59AM
(#22032179)
As Gary Bernhardt said, and I quote often, it makes sense when it’s right half of the ass.
wow, have seen many of Gary's talks but not this one until now; clearly I missed a gem
> Google-caliber people might be able to be reasonable about this...
I'm not sure about that. Google certainly has some very talented people among their developers, but most of them are so bad at programming that they had to invent their own heavily watered down programming language.
Shell is brilliant until you need to keep a filename in a variable. Or, worse, read filenames from the output of a command. Since basically everything except '/' and '\0' is a valid filename character, the potential for mishaps or exploits is huge.
That's where we came in with the need to use "$@" vs the unsafe-by-default bare $@.
Re:Bash $* and $@ (2017)
by TazeTSchnitzel on Monday January 13, 2020 @01:07PM
(#22036929)
> here's no competition for a shell when you need to do what shells are meant to do: chaining invocations, gluing and piping output, and so on
There is no reason this shouldn't be easy to do in Python too, if it is then it is something a library should fix.
Re:Bash $* and $@ (2017)
by DonHopkins on Monday January 13, 2020 @01:23AM
(#22032270)
But bash IS evil.
Re:Bash $* and $@ (2017)
by cookiecaper on Monday January 13, 2020 @07:34PM
(#22040488)
I mostly agree, but it's sometimes a necessary evil. There's a reason I praised shell languages in general rather than bash specifically; fish shell, for instance, is much more comfortable.
Why?
In most languages, you don't need to know/understand this much minutiae about string handling; as an example, I've been doing open source dev for years now in Bash and I never knew the distinction OP posted.
At work lately, there's been a spate of contorted "just why?" Python scripts that could've been accomplished elegantly in a handful of lines of shell. While no one would select shell languages as the ideal for a lot of complex logic, data parsing, etc., there's no competition for a shell when you need to do what shells are meant to do: chaining invocations, gluing and piping output, and so on.