131–140 of 191 posts
Is : the same as `true` ?
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t...>
The most important differences seem to be:
* `:` is a builtin vs. `true` is an utility * passing arguments to `:` is safe but for `true` its not hence `:` is the right thing to use here.
I've never liked cleverness in scripting when clarity costs effectively nothing. This is one of those clever things, similar to people using perl5 use trinary expressions. Like, are you TRYING to make this obtuse and hard to read?
The trinary is semantically just an if expression though. Perl inherits C's problem that `if` can't be used in an expression context: my $x = if ($cond) { 1 } else { 2 }; # Syntax error Because of this, Perl introduces a second syntax to plug the gap: my $x = $cond ? 1 : 2; That expression is neither obtuse nor hard to read. Something like the code below is hard to read: my $fee = $is_member ? ($is_student ? $student…
I was complaining of the "cleverness" of them, when working or analyzing a codebase with people swapping from if/else loops to trinaries.
I prefer clarity and a bit more verbosity than a per5-ism. If that means a 5 line loop that I can easily follow, then so be it. 1 liners that effectively say "lookie at me im a l33t developer" are a very bad code smell, and make maintenance harder each cycle of more cleverness.
Articles like this are fun but they all come from posix shell syntax being fundamentally bad for scripting/programming. All the piping stuff is great, of course. And the overall ecosystem is great. But the interpretation of the script itself working by a series of string substitutions is a mechanism we wouldn't accept in a regular programming language. And there's no excuse for it really, except that shell syntax is…
I feel the need to push back on this perspective. Old doesn't imply arcane. It instead can (and does, in this case) mean that it won out over the course of decades against other less worthy alternatives. Although you can write "programs" in sh, the shell syntax was never meant to be anything like a systems or application programming language. It was meant to efficiently automate systems tasks. It is kind of like the…
Shell was designed to launch processes easily. Unix philosophy pushed to make every function an application. And that's ultimately what shell "syntax" is.
There's shockingly little syntax in the shell. A lot of what we think of as "shell syntax" is actually full blown (standard) programs which the shell is launching. My favorite of which is `[`.
What makes shell unique vs all other programming languages is it puts launching processes first. It has no friction there because if it did, it wouldn't work.
This is also what I think is gross about shell. Every other scripting language has at least some friction when launching other processes and that's usually a good thing IMO.
I use the colon as EDITOR with Git when I want to do an interactive rebase combined with auto squash without having to edit the todo list. I have an alias[1] for that which I call a quick interactive rebase: riq = -c sequence.editor=: rebase --interactive [1]: https://github.com/fphilipe/dotfiles/blob/94f2ff70bade070694...
That seems unsafe. It assumes that the editor is started via a shell command, and not executed directly. But there is no actual binary /usr/bin/: but there is a /usr/bin/true; I would use that instead.
What if there was a less cryptic way to have mandatory arguments, something harder to get wrong, like param( [parameter(mandatory)] $name ) "Hello, $name!" And then: $ ./script.ps1 Dave Hello, Dave! $ ./script.ps1 -name Dave Hello, Dave! $ ./script.ps1 cmdlet script.ps1 at command pipeline position 1 Supply values for the following parameters: name: Or non interactively: $ pwsh -nonint ./script.ps1 script.ps1: Cannot…
PowerShell is a bad choice for the system shell because it's too complex. I'm not trying to justify all the quirks of Unix Shell, but minimalism is a very important feature of such a tool. Another important feature of a tool like this is the ability to tolerate errors: I can't imagine a Linux today that would be able to even boot if the shell was extra pedantic about errors. A lot of mostly irrelevant things routinel…
Articles like this are fun but they all come from posix shell syntax being fundamentally bad for scripting/programming. All the piping stuff is great, of course. And the overall ecosystem is great. But the interpretation of the script itself working by a series of string substitutions is a mechanism we wouldn't accept in a regular programming language. And there's no excuse for it really, except that shell syntax is…
I feel the need to push back on this perspective. Old doesn't imply arcane. It instead can (and does, in this case) mean that it won out over the course of decades against other less worthy alternatives. Although you can write "programs" in sh, the shell syntax was never meant to be anything like a systems or application programming language. It was meant to efficiently automate systems tasks. It is kind of like the…
Earlier quoted context omitted.
The trinary is semantically just an if expression though. Perl inherits C's problem that `if` can't be used in an expression context: my $x = if ($cond) { 1 } else { 2 }; # Syntax error Because of this, Perl introduces a second syntax to plug the gap: my $x = $cond ? 1 : 2; That expression is neither obtuse nor hard to read. Something like the code below is hard to read: my $fee = $is_member ? ($is_student ? $student…
You misunderstand. I didnt need an explanation of how they worked. Im refuting that they are a good practice. I was complaining of the "cleverness" of them, when working or analyzing a codebase with people swapping from if/else loops to trinaries. I prefer clarity and a bit more verbosity than a per5-ism. If that means a 5 line loop that I can easily follow, then so be it. 1 liners that effectively say "lookie at me…
And every language has its idioms that are incomprehensible until you learn them. This isn't clever code so much as shorthand for common things.
Articles like this are fun but they all come from posix shell syntax being fundamentally bad for scripting/programming. All the piping stuff is great, of course. And the overall ecosystem is great. But the interpretation of the script itself working by a series of string substitutions is a mechanism we wouldn't accept in a regular programming language. And there's no excuse for it really, except that shell syntax is…
I feel the need to push back on this perspective. Old doesn't imply arcane. It instead can (and does, in this case) mean that it won out over the course of decades against other less worthy alternatives. Although you can write "programs" in sh, the shell syntax was never meant to be anything like a systems or application programming language. It was meant to efficiently automate systems tasks. It is kind of like the…
Articles like this are fun but they all come from posix shell syntax being fundamentally bad for scripting/programming. All the piping stuff is great, of course. And the overall ecosystem is great. But the interpretation of the script itself working by a series of string substitutions is a mechanism we wouldn't accept in a regular programming language. And there's no excuse for it really, except that shell syntax is…
I don’t agree with this assumption that shell should use mechanisms we accept in “regular” programming languages, whatever that means. And why not the other way around? Why do we accept mechanisms in programming that we wouldn’t accept in a shell? There are layers of assumption in your assumption.
I also disagree with lumping scripting and programming together. Those are two different activities, and shell is better at scripting than programming, and it’s better at scripting than programming languages.
Try using python as your shell, and you’ll find out that python is fundamentally bad as a shell REPL. The shell is necessarily different from python or C++ or , starting with the ability to run command lines by typing them, with zero extra syntax. That is something regular programming languages can’t do, and it leads directly to the need for string substitution rules.
If you want a shell made out of a good programming language… make one! People have been thinking about this for decades and nobody has come up with a good one, because shell languages like bash are better at shelling than programming languages.