Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A shell colon does nothing. Use it anyway

refp.se

Post reply on HN
Print view View original

151–160 of 191 posts

Re: A shell colon does nothing. Use it anyway

#151

Post by dahart »

garethrowlands wrote: post #116
bityard wrote: post #103

Earlier quoted context omitted.

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…

There are plenty of alternative shells that don't suffer these problems. Posix syntax didn't win because it was better - it's the classic 'worse is better'. > Old doesn't imply arcane. Indeed so. For example, awk is about the same age but doesn't suffer the same problems. > the shell syntax was never meant to be anything like a systems or application programming language A programmable shell is not only like a progra…

> overall, scripting is programming.

This is a logical statement that is technically true while not matching real-world experience. Scripting as a type of programming is different from application development programming, and scripting needs differences in features and interface to be convenient and comfortable.

> There is nothing in the problem domain that requires the posix string-substitution problems.

What do you mean? Environment variables and command line execution both separately lead to string substitutions. The fish shell uses string substitutions.

You emphasized ‘requires’ which again might make your statement technically true while still missing the experiential forest for the logical trees. You can use x86 assembly for your shell if you want, there’s nothing that “requires” posix. The reason string substitutions exist is because they’re useful and convenient; the alternatives are verbose and klunky.

Re: A shell colon does nothing. Use it anyway

#152

Post by Brian_K_White »

kevincox wrote: post #2

I am not a huge fan of most of these, but a few do seem useful. : "${1:?missing argument, aborting!}" I wouldn't use this because I would want to give $1 a name for the rest of the script, so I would assign. But it can be a nice way to give a clear error for missing required environment variables. Many of the others (like truncating files) are probably more clearly written with dedicated commands, but may come in use…

I use this for setting overridable defaults (this should hopefully actually be in the article I haven't read yet)

: ${DEBUG:=false}

debug is not only false, but garanteed to be set to something so that elsewhere the places that use it don't need extra syntax and checking in case it's empty, and yet you can just set it from the parent environment to override without touching the script or adding a commandline args parser.

And do me, reading this is almost as easy on the brain as just plain DEBUG=true.

Even if you aren't familiar with the extra syntax, like you're someone else in the future who needs to look at it, the two important words pop out, and probably don't mean NOT because whatever those extra bits mean, there's no !. So you get the idea well enough & cruise on.

...[edit] yep it's in the article. but one thing isn't, exactly

    condition && {
        then-cmd   # might exit > 0
        :          # ensure this block ends true
    } || {
        else-cmd
    }
In other words, maybe you should have figured out some other way to write the whole construct, but IF you want to write the if/else this way maybe for just readability or organization, and you want the else-block to only hinge on the initial condition and not also on whatever the then-block might do, then you need a safety-true at the end of the then-block.

Re: A shell colon does nothing. Use it anyway

#153

Post by mondainx »

shevy-java wrote: post #29

This is an excellent article that helps people decide against writing shell scripts. I abandoned doing so shortly after I switched to linux. Since then I was also using ruby. I still do not understand why people would prefer shell scripts over ruby (or python). On systems without ruby or python, one may see a benefit in using shell scripts; other than that I fail to see why shell scripts are necessary. Shell scripts…

Mostly agree, but many times there is no python nor ruby on a system, whereas there may always be shell available for scripts like these.

Re: A shell colon does nothing. Use it anyway

#154

Post by tejtm »

lynndotpy wrote: post #137
bityard wrote: post #103

Earlier quoted context omitted.

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…

One of these are not like the other. Python is perfectly serviceable as a shell, to the extent that one could largely replace bash with the Python REPL if they wanted.

python you say?

Pray tell which one of the myriad is the true one?

And do not worry, no one would be rash enough to bring in external dependencies it is just too darn inconvenient.

I should probably drink my coffee before posting, be less grumpy.

Re: A shell colon does nothing. Use it anyway

#155

Post by kazinator »

refp wrote: post #49
brabel wrote: post #45

Earlier quoted context omitted.

It’s very common that the most upvoted comment on a post is a mistaken correction. People seem to love comments seemingly proving that the post is wrong without actually checking anything. And once it has enough upvotes a big discussion may follow up with personal attacks on the author or other questionable comments, while the people trying to point out that the post actually is accurate get either buried under the c…

I have never been in this situation before but I do agree with you, and honestly it feels very bad. I saw the comment when it was posted and, perhaps naively, thought "oh well, no one will care - its just another fluff comment". Fast-forward to seeing that comment climb up the ranks, posted by a person who has 270x my karma, who seemingly gets upvotes by just.. writing things? no proof? no rationale? nothing? Yeah, f…

As a programmer you will be in the situation many times when you write something that has to be a certain way for reason (like portability) and someone won't see it (possibly a more senior person). That should not feel bad at all, or discouraging; there is no egg on your face!

Or, you might not even write that something yourself; you just understand why it is that way and leave it alone in the refactoring that you are doing; then you get a review comment like "you can get rid of this from here", and you have to respond "no you can't, because ...".

Re: A shell colon does nothing. Use it anyway

#156

Post by embedding-shape »

delta_p_delta_x wrote: post #56
IdiotSavage wrote: post #51

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 needs to become more ubiquitous. There are so many things about it that once considered in greater detail make so much sense. Parameter setup, typing, and naming. Flow control. Object-oriented scripting. Built-in parsing for recursive data types like JSON, HTML, XML. And in my opinion, the most slept-on: the fact it runs on the CLR and direct access to .NET objects and types which means access to P/Invoke…

I'm curious, have any good examples of projects in the ~1K LOC range of PowerShell, so I could get a taste for how something like that would look like? Beyond that I tend to go for "real" programming languages, or just start with Babashka, but still curious to see projects other PowerShell fans would consider "well written/designed" :)

Re: A shell colon does nothing. Use it anyway

#157

Post by [deleted] »

brabel wrote: post #45
refp wrote: post #34

Earlier quoted context omitted.

They are NOT superflous, and all you need to prove it is `zsh` (but there are others that follow suit in similar fashions): zsh% echo "hello world" > data zsh% So, if you want something that "everyone can use" without going into details about the difference between commonly used shells.. you'd use the null-command. --- and given that we use the null-command, it _WILL_ behave different with or without subshell.. and a…

It’s very common that the most upvoted comment on a post is a mistaken correction. People seem to love comments seemingly proving that the post is wrong without actually checking anything. And once it has enough upvotes a big discussion may follow up with personal attacks on the author or other questionable comments, while the people trying to point out that the post actually is accurate get either buried under the c…

[deleted]

Re: A shell colon does nothing. Use it anyway

#158

Post by refp »

kazinator wrote: post #142
refp wrote: post #34

Earlier quoted context omitted.

They are NOT superflous, and all you need to prove it is `zsh` (but there are others that follow suit in similar fashions): zsh% echo "hello world" > data zsh% So, if you want something that "everyone can use" without going into details about the difference between commonly used shells.. you'd use the null-command. --- and given that we use the null-command, it _WILL_ behave different with or without subshell.. and a…

zsh% /dev/null && echo READABLE # Maybe zsh still reads the entire file and copies it to /dev/null, which would be a severe performance problem for large files. The colon by itself, without the subprocess, also prevents the dumping to stdout: zsh% : However, with the subprocess parentheses, we can redirect the nonexistence diagnostic to /dev/null, which I don't see mentioned or exemplified in the article: zsh% : /dev…

I think you should take a deep breath and read this updated FAQ:

https://refp.se/articles/your-shell-and-the-magic-colon#why-...

I am not asking anyone to put this in production, it is a tongue-in-cheek/cute way of explaining/showing what the null-command _can_ do, not what it _must_ do.

No, any distro that stopped shipping entities mentioned to use only null-command variants.. well, I'd save whatever your end goal is to a meeting with them.

Just enjoy the article for what it is — a piece of trivia.

Best Regards, Filip Roséen - refp

Re: A shell colon does nothing. Use it anyway

#159

Post by axus »

jghn wrote: post #5
zaptheimpaler wrote: post #4

life is way too short to deal with this nightmare of a language and its 50000 footguns for anything longer than a 2 line script, especially in the age of LLMs. Just write a python/TS/any real language script instead. Bash is great for the command line, it should be limited to use there.

It turns out that LLMs are really good at writing bash too. even perl! maybe we should rethink some of these lost bits because we no longer need to worry about the arcane parts.

An LLM taught me how to use the shell colon. Shell scripts are short enough that it's been worth my time to edit the AI's work.

Re: A shell colon does nothing. Use it anyway

#160

Post by Brian_K_White »

ensure true

It's almost but not quite in the article. And you don't necessarily always want this. It depends if you want else-cmds to run only when condition fails, or when either condition or then-cmds fails.

You could write the word true instead of :, coincidentally showing that : never really was a no-op in the first place. It's so not-no-op that there is even an entire external executable /bin/true to do the same job.

    condition && {
        then-cmds   # might exit > 0
        :           # ensure this block ends true
    } || {
        else-cmds
    }
Post reply on HN