Live data from Hacker News

A shell colon does nothing. Use it anyway

refp.se

171–180 of 191 posts

Re: A shell colon does nothing. Use it anyway

#171

Earlier quoted context omitted.

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

I basically agree with these tradeoffs (you should never be pulling in dependencies outside the builtins), but let's look back to GP:

> Comparing the shell to C, Go, Rust, Python, or JavaScript is crazypants. It has a different job than those, so of course it will look and feel different!

The point was just a small one, that Python is not like the others. C, Go, and Rust do not come with REPLs. Node is plausible to use as an OS shell but I've never heard of anyone doing that. Python is the only one of those I've used as a shell or have heard of others using as a shell.

Again, I'm not advocating for Python as a good general-purpose shell. I'm only making the small claim that C, Go, Rust, and (to a smaller extent) JavaScript cannot be be used like bash. Python could be used as a shell.

Re: A shell colon does nothing. Use it anyway

#172

Earlier quoted context omitted.

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…

I think we're talking past each other. You are largely not understanding the point I'm saying. I agree that Python, as a shell and scripting language, will have different ergonomics and tradeoffs compared to Bash.

The point I am making is that, of the listed languages, Python is far more comparable to Bash than the others. Suppose you had no choice but to use one of the following executables in place of /usr/bin/bash

- go - gcc - rustc - node - python

You would choose Python, of course. Plausibly node, but certainly not any of the other three.

Re: A shell colon does nothing. Use it anyway

#173

Earlier quoted context omitted.

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…

I think we're talking past each other. You are largely not understanding the point I'm saying. I agree that Python, as a shell and scripting language, will have different ergonomics and tradeoffs compared to Bash. The point I am making is that, of the listed languages, Python is far more comparable to Bash than the others. Suppose you had no choice but to use one of the following executables in place of /usr/bin/bash…

OK, but you to admit "largely replace bash with the Python REPL" is something of a stretch.

I didn't read the list of languages given by the earlier poster as specific list, I read them as "". And sure, a scripting language is closer to a shell than a compiled language, but I wouldn't say either Python or Node treat shell commands as first-class citizens, as fellow scripting languages Perl and Ruby do... and even the I wouldn't use Ruby or Perl REPLs as shells, because they're still actually programming languages, not text-based user interfaces to your OS.

    Perl:   $x = `ls -l`;
    Ruby:   x = `ls -l`
    Python: import subprocess; x = subprocess.run(args=["ls", "-l"], capture_output=True).stdout
    Node:   let x = (await require('util').promisify(require('child_process').exec)("ls -l")).stdout

Re: A shell colon does nothing. Use it anyway

#174

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 disagree. I see shell syntax as an “inversion” of normal quoting rules. Normally quoting is the default but to achieve anything special you have to use an escape. Conversely, in shell, quoting is not necessary but any special character will likely have unwanted behaviour unless you quote.

This is handy for quick scripting as a natural extension of a command line interface. A counterexample might be an equivalent script using the Python subprocess module. For a simple script, the required extra quoting overhead is not worth the trouble. For something complicated it’s essential and a shell script is no longer suitable. For something in the middle, a carefully crafted shell script (eg. one that passes shellcheck) may be the most suitable solution depending on the situation.

Both cases have their place. It’s about using the right tool for the job.

Re: A shell colon does nothing. Use it anyway

#175
post #26

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.

Python startup time is a problem. I don't know about ts but I bet it's worse.

TS compiles to JS, so when you actually execute a script, you’re just starting Node, Deno, etc. with a JS file. Any of those are probably faster to start than Python. Deno in particular starts in around 15-60 milliseconds. Even if it has to compile the Typescript - which is a one-time operation if the script isn’t changing - it still typically starts in under 250ms.

Re: A shell colon does nothing. Use it anyway

#176

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.

There’s a good chance that the people writing it will probably forget what it does in six months too :P

Re: A shell colon does nothing. Use it anyway

#177

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…

I think the point is that worse is better. There is incredible power in a standard (mostly) predictable platform, even if it could be done better.

Re: A shell colon does nothing. Use it anyway

#178
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…

$1 might also just be the first parameter for a function call, so you might not need that parameter to have a specific/readable name if the function is not very complex or long. I have plenty in my dot-files that are just one-line functions that don't need to be three-line functions just to give the single parameter it accepts a name.

Re: A shell colon does nothing. Use it anyway

#179

This "hidden knowledge" is fun to read but pain to remember and use, especially when working with multi-platform environments // Switched from bash to plain python scripts for shell stuff everywhere several years ago, and never looked back into bash zoo anymore. Stable syntax across Win/Mac/Linux, no bash/zsh/msys2 obscure differences, normal errors and Clause writes scaffolds quick and flawless anyway

I guess if you're never calling out to any third-party python libraries, that can work.

I'd never call Python "portable" though if you have outside dependencies.

Re: A shell colon does nothing. Use it anyway

#180

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.

What other language is it as easy, fast, and painless to work with file contents? I can toss data down and lift it back up with some symbols and a path, none of Python's "errrm, how would you like to open that file " handholding. And why the hell would I want to go learn TypeScript!?!?

Sometimes I feel like the people on HN repeating the trope "uhhh if you need ____ go learn a real language!" are just bad at writing shell scripts.

Post reply on HN