there are some early unix tapes floating around, and in those early shells, i'm fairly certain the colon was one of only two special-cased code paths after the command line was parsed. does anyone recall more specifically?
A shell colon does nothing. Use it anyway
81–90 of 191 posts
Re: A shell colon does nothing. Use it anyway
#82I actually did absolutely need it recently when I golfed together a shell script that is simultaneously a valid YAML file [0]. Sometimes having no-op tokens is nice!
Re: A shell colon does nothing. Use it anyway
#83I 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...
nice dotfile
Re: A shell colon does nothing. Use it anyway
#84there are some early unix tapes floating around, and in those early shells, i'm fairly certain the colon was one of only two special-cased code paths after the command line was parsed. does anyone recall more specifically?
I think colon at the start of a line was used for labels for goto statments.
https://www.in-ulm.de/~mascheck/bourne/PWB/goto.1.html
DESCRIPTION
Goto is allowed only when the Shell is taking commands from
a file. The file is searched from the beginning for a line
beginning with `:' followed by one or more spaces followed
by the label. If such a line is found, the goto command
returns. Since the read pointer in the command file points
to the line after the label, the effect is to cause the
Shell to transfer to the labelled line.Re: A shell colon does nothing. Use it anyway
#85I've read through all of the examples in the article & they all seem to serve to sole purpose of turning readable multiple line code into one-liners. One-liners are a cool little artifact of early shell culture & are sometimes still useful today if they're short to avoid the readability problems of `/` when copy pasting a quick shell command to run, but they have no place in scripts. None of this seems useful to me.…
Bash scripts should only be used for quick and dirty tasks where brevity is a major benefit. Don’t pretend bash can be readable and maintainable. If you want that use another language that sacrifices brevity for clarity.
First I agree that bash scripts should only be used for quick or small (& ultimately mostly personal unshared) tasks. There's absolutely no need for it to be either "dirty", & as mentioned in my post, brevity has no material benefit in this context.
I want my personal local utility/productivity scripts to be readable: quick to write & quick to modify on the fly. Brevity doesn't help here - wpm optimises for natural language typing & that translates better to idiomatic logical block structures than to symbol-heavy one-liners.
I also want the same for the small bash snippets in my CI jobs - this is a particular example where brevity is actively bad: this encourages folk to inline their bash snippets in yaml (no syntax highlighting & unlintable) when they should be packaged in script files in CI directories.
Re: A shell colon does nothing. Use it anyway
#86For decades I used bash and never knew and saw this syntax. And recently discovered that by a code generated by Claude.
And now I see this article. So I guess that it is a construct suddenly popularized by llm.
Re: A shell colon does nothing. Use it anyway
#87Why take a perfectly readable if-statement and turn it into something, 99.9% of people would need to lookup. Concise != better. You can make it one line with: [ -z "$1" ] && { echo "missing argument, aborting." 1>&2; exit 1 }
This question seems to pop up all over the place, so I took some time to answer it here:
https://refp.se/articles/your-shell-and-the-magic-colon#why-...
Re: A shell colon does nothing. Use it anyway
#88Why take a perfectly readable if-statement and turn it into something, 99.9% of people would need to lookup. Concise != better. You can make it one line with: [ -z "$1" ] && { echo "missing argument, aborting." 1>&2; exit 1 }
I believe you missed a semicolon after `exit 1` and before `}`. `}` closes the opening `{` only at the start of a command (POSIX rules; don't remember now if bash recognizes it when it's just a command argument).
I'm just too used to how parsing works in Zsh. For bash and sh, there is indeed should be a semicolon.
Re: A shell colon does nothing. Use it anyway
#89Well that's exciting. I learned a lot of uses for ":" today. However, the only one I already knew... if some-command; then : # command required else echo "command failed" fi I used to do that until I learned of if ! some-command; then echo "command failed" fi It's in the POSIX standard so it's not just a bashism: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... > If the pipeline does not begin with the…
https://github.com/anordal/shellharden/blob/master/how_to_do...
TL;DR: The old-school empty branch preserves $?, while logical negation doesn’t. Sure I guess, but this is not always relevant.
Re: A shell colon does nothing. Use it anyway
#90I 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…
Yo, author here. You are very much correct and I 100% agree with you, I have updated the first example to include a snippet where a proper env-var is used to show of the automatic diagnostic. Thanks for your feedback, much much appreciated!
For a short-lived script, the `${1:?missing argument}` stuff may be useful, but usually, I want to print some longer usage or help text in the error case.
I usually go with something like this:
set -eu
function eusage() {
echo "Usage: $0 " >&2
echo "Error: $@" >&2
exit 1
}
infile=${1:-}; shift || eusage "Missing input filename"
outfile=${1:-}; shift || eusage "Missing output filename"