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

161–170 of 191 posts

Re: A shell colon does nothing. Use it anyway

#161

Post by kazinator »

refp wrote: post #158
kazinator wrote: post #142

Earlier quoted context omitted.

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 i…

I understand; it's just "here are these cool, obscure things you can do with the colon". I had no idea it was supposed to be "here are these cool, obscure things yuo can do with the colon, carefully coded to work on numerous POSIX-like shells that are in widespread use.

To me, it's "cool" that you can just do "For decades, I used "> file" to truncate files to zero length, never with a colon command; the example makes it look as if the colon is required in order for the command line to be valid and for the effect to take place.

BTW I noticed that zsh not only does the cat-like dumping to stdout in non-interactive mode, but it also does the redirection to the pager!!! So if you drop that test into a non-interactive script, and it finds an existing file, if that script is run in a terminal session, it will pause for input.

Re: A shell colon does nothing. Use it anyway

#162

Post by teddyh »

jeremyjh wrote: post #134
teddyh wrote: post #119

Earlier quoted context omitted.

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.

It assumes git works the way that git works, and that git will not break backwards compatibility in the future. I think the same can be said of any alias in git.

The question is, is this behavior documented to run the command in a subshell? If it’s only documented to split on spaces and expand environment variables, the git command could change the implementation at any time.

Re: A shell colon does nothing. Use it anyway

#163

Post by 1vuio0pswjnm7 »

Whats the advantage of the colon for the truncation example

  >file1 >file2
versus

  : >file1 >file2
I've done quick and dirty, interactive truncation like the former for many years, no colon. But I would not use it in scripts

According to https://www.in-ulm.de/~mascheck/bourne/ SVR4 (1989) had a bug when using this method in a for or while loop and this bug showed up in a SunOS 5 variant, too

Apparently, early in the shell's evolution, : was used as a comment marker before # was added

Single quotes could be used to prevent undesired behaviour

   : echo output 1>&2

   : `echo output 1>&2`

   : '`echo output 1>&2`'
System III (1981) also had a bug when using : as a substitute for true

   if false;then :;fi
returned 1 instead of 0

Re: A shell colon does nothing. Use it anyway

#164

Post by lynndotpy »

tejtm wrote: post #154
lynndotpy wrote: post #137

Earlier quoted context omitted.

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.

I think you are reading something into my post that isn't there. You surely do not believe I am arguing that Python is a shell language without tradeoffs.

Of the languages listed in GP, only Python and JavaScript are scripting languages with REPLs like Bash. Of those two, Python is far more serviceable for what one uses bash for, even in embedded applications (with MicroPython).

Perl, Awk, Ruby, and Lua are also scripting languages one can use in the course of OS scripting. (Your distro probably uses some combination of these, including Python.) Of these, at least Ruby can also be used as a shell.

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

You've basically got it, that's just `which python`

I use Python for longer scripts where script maintainability is a priority and external libraries are unnecessary, and as a general shell when I also want my shell to be a calculator, especially when computing on a smartphone (with an appropriate pythonrc).

The key thing is that I already know Python and I find Python's warts more palatable than those on Bash.

Re: A shell colon does nothing. Use it anyway

#165

Post by lynndotpy »

amiga386 wrote: post #149
lynndotpy wrote: post #137

Earlier quoted context omitted.

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.

I'd be jumping out the top storey window after about 2 minutes of being required to use Python as a shell. Python is a full-on programming language. Its REPL is a REPL for that language. Interacting with the OS and filesystem is a niche, tucked away in a corner of the language. It has has none of the ergonomic affordances needed to be the user interface for interacting with files and processes. Here are some simple c…

Yes, someone who has no idea how to use their shell and tries to get around by making arbitrary guesses will suffer. This is true for bash as well. It's no reason to kill yourself immediately.

Re: A shell colon does nothing. Use it anyway

#166

Post by rgrau »

dtj1123 wrote: post #93
rgrau wrote: post #74

Nice one! I love those weird bash tricks. Some of the examples here are interesting, but they show parameter substitution more than colon itself: https://tldp.org/LDP/abs/html/parameter-substitution.html In small scopes, I tend to inline the `:?` validation inside the arg of the command. `echo "${1:? first param required}"` Another usecase is to use colon in the body of a while loop, while doing work in the condition…

I hate weird bash tricks with a passion. The extent to which the script author gets to feel smart and efficient is exactly the extent to which the future reader of the script gets to feel like an idiot.

So true. I think most of us who learned "advanced" bash is after being tired of feeling like an idiot looking at long bash scripts.

Usually, those scripts are written by people who didn't learn the "weird tricks", and use global variables (they didn't learn that `local` creates local variables), for example.

In bash, many times the "dumb way" takes 10 times more lines, and it's probably buggier than the "smart tricky way". So, in the end it's your choice what side you pick, and when to stop. Or, use a "real programming language" (I hate when people say this LOL)

After a while, you get a bit of stockholm syndrome, and you're just fine with bash as an orchestration language, and lean into unix principles. I accept its limitations, and I think it keeps me on my toes as it repels bloat.

idk if you were expecting an answer, but bash lives in this liminal space in the tower of languages that is worth a thought.

Re: A shell colon does nothing. Use it anyway

#167

Post by andrehacker »

lynndotpy wrote: post #164
tejtm wrote: post #154

Earlier quoted context omitted.

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.

I think you are reading something into my post that isn't there. You surely do not believe I am arguing that Python is a shell language without tradeoffs. Of the languages listed in GP, only Python and JavaScript are scripting languages with REPLs like Bash. Of those two, Python is far more serviceable for what one uses bash for, even in embedded applications (with MicroPython). Perl, Awk, Ruby, and Lua are also scri…

I think the point was that Python, as a language and ecosystem, has experienced a number of breaking changes over the years. In practice, that means code written only a few years ago may no longer run without specific versions of Python and a collection of dependencies, many of which have since been replaced by newer, incompatible implementations.

What I appreciate about the traditional shell languages is their remarkable stability. Shell scripts written in 2000, or even earlier, are often still able to run today with little or no modification. By contrast, Python applications frequently require recreating a historical runtime environment, including older language versions and dependencies, many of which have accumulated significant security vulnerabilities over time.

Interestingly, apart from the various shell languages, Perl is probably one of the strongest alternatives in this regard. The Perl community has placed a high value on backward compatibility, allowing older code to continue functioning while the language itself remains actively maintained and up to date.

Re: A shell colon does nothing. Use it anyway

#168

Post by notnmeyer »

archargelod wrote: post #73

Why 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 }

the people writing it are doing it for themselves probably. i wouldn’t expect it to survive a code review. the necessity of using esoteric bash features or syntax is a pretty good smell that you should be using something else imo.

different strokes of course.

Re: A shell colon does nothing. Use it anyway

#169

Post by amiga386 »

lynndotpy wrote: post #165
amiga386 wrote: post #149

Earlier quoted context omitted.

I'd be jumping out the top storey window after about 2 minutes of being required to use Python as a shell. Python is a full-on programming language. Its REPL is a REPL for that language. Interacting with the OS and filesystem is a niche, tucked away in a corner of the language. It has has none of the ergonomic affordances needed to be the user interface for interacting with files and processes. Here are some simple c…

Yes, someone who has no idea how to use their shell and tries to get around by making arbitrary guesses will suffer. This is true for bash as well. It's no reason to kill yourself immediately.

I put it to you that a "shell" that does not natively run the executable programs you type is a non-starter as a shell.

I would be ready for the window if I had to type

    import subprocess; p = subprocess.run(args=["curl", "-s", "http://example.com/"], capture_output=True); fh = open("output", "wb"); fh.write(p.stdout); fh.close()
rather than

    curl -s http://example.com/ >output
There are certainly attempts to create a shell that's powered by Python and allows the Python language into it, but one could not "largely replace bash with the Python REPL". Only people who didn't want a shell in the first place would think that reasonable.

Re: A shell colon does nothing. Use it anyway

#170

Post by tyre »

andrewl wrote: post #139
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…

I think Bash won as Bityard says above, in the sense that COBOL won, which was because it was everywhere (approximately) and then when another system was being built to do something in COBOL’s niche COBOL was the obvious choice. Once it was sufficiently established it won by inertia and absolutely not because it was the better language. Or maybe it was the better language in its time, but it certainly is not now. And…

In a similar way that Python won, despite having some pretty delulu characteristics.

Whitespace sensitivity is horrendous (can’t autoformat, no multi-line lambdas, bonkers inline list comprehensions) but here we are.

Post reply on HN