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

121–130 of 191 posts

Re: A shell colon does nothing. Use it anyway

#121

Post by teddyh »

I once created a set of shell functions which I wanted to have a docstring-like functionality. The solution I came up with was to have each shell function start with the : command with a string as an argument. Since : is an actual command, not a comment, it was preserved as part of the function, and could be extracted at runtime using relatively simple parsing to do introspection.

Example:

  foo(){
    : "This is a docstring for the foo() function"
    bar --verbose | baz --quiet
  }
(Repost of https://news.ycombinator.com/item?id=29152308>)

Re: A shell colon does nothing. Use it anyway

#123

Post by kps »

Here's another tip I picked up last millenium: If you're using a GUI and like decorating your shell prompt with information, format it like this:

    : stuff;
Then you can copy/paste entire lines of commands.

(Yes, this assumes you don't put naughty fragile stuff in your prompt. Buy you're smart enough not to do that.)

Re: A shell colon does nothing. Use it anyway

#125

Post by garethrowlands »

nekusar wrote: post #108

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_member_fee : $member_fee)
        : ($is_student ? $student_fee        : $standard_fee);
It's equivalent to the following code that uses `if`:

  my $fee;
  if ($is_member) {
      if ($is_student) {
          $fee = $student_member_fee;
      }
      else {
          $fee = $member_fee;
      }
  }
  else {
      if ($is_student) {
          $fee = $student_fee;
      }
      else {
          $fee = $standard_fee;
      }
  }
But ideally you would want to write this:

  my $fee =
    if ($is_member) {
        if ($is_student) {
            $student_member_fee
        }
        else {
            $member_fee
        }
    }
    else {
        if ($is_student) {
            $student_fee
        }
        else {
            $standard_fee
        }
    };
Though, of course, perl5 doesn't allow that.

Re: A shell colon does nothing. Use it anyway

#126

Post by garethrowlands »

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…

I like your 2026 perspective. Objectively, the posix shell syntax is genuinely bad, even though the overall system that it enabled is amazing. It's a very old system that took off because it solved a problem - history is kind to it because of that context. Though, awk is around the same age and provides a proof-by-existence that posix shell syntax didn't have to be make these mistakes.

Re: A shell colon does nothing. Use it anyway

#127

Post by garethrowlands »

m2f2 wrote: post #62

I usually skip the get option builtin, and use : as... while : ; do case "$1" in "") break;; -f|-foo) shift; whatever;; *) usage; exit 1;; esac done For this... instead if something; then true else echo ERROR exit 1 fi Using : would be too much here. For anything else including json etc. I usually go to duckdb. Awesome support, single file install, readable, easy to maintain. Powershell on Linux or Unix? Just another…

Yeah, I don't see pwsh finding a place in the ecosystem. Even oil or fish struggle. Their place was mostly taken by python (which is a huge dependency but not another huge dependency).

Re: A shell colon does nothing. Use it anyway

#128

Post by IdiotSavage »

crabbone wrote: post #67
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 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…

> 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 routinely fail on boot and during normal operation. Stamping them all out is an arduous...

You seem to be implying PowerShell aborts on any error. That's not the case:

https://learn.microsoft.com/en-us/powershell/module/microsof...

Re: A shell colon does nothing. Use it anyway

#129

Post by garethrowlands »

PunchyHamster wrote: post #21

> Though.. what if I told you the above four lines could be replaced by just... one? I'd reject the pull request. Bash is already bad as programming language (the goodness of language for long code is inversely proportional to how nice it is for shell one-liners), this is just turning "bad" into "line noise" If your bash script takes more than one screen, rewrite it in Python, hell, rewrite it in Perl, even that's be…

I totally agree with you.

> the goodness of language for long code is inversely proportional to how nice it is for shell one-liners

Well, except for this bit. Oil or fish and awk are perfectly fine for one liners but don't repeat the mistakes of posix shell syntax.

Re: A shell colon does nothing. Use it anyway

#130

Post by ndsipa_pomu »

amelius wrote: post #98
garethrowlands wrote: post #94

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…

Yes a large percentage of bash scripts fails if you feed them filenames with spaces or other special characters. Or a large amount of filenames near the Unix maximum commandline length. Bash et al are great for command line use, but produce a situation of really bad engineering hygiene when used in scripts. Do not use. Stay away. Bash et al considered harmful. Red flags on job interview when referenced.

Whilst I agree that Bash makes it far too easy to do it wrong, it's not too tricky to write scripts that don't have those issues.

Possibly the most important tip is to use ShellCheck (https://www.shellcheck.net/) as a linter on your scripts and work through the various warnings to eliminate them. For the rare times that ShellCheck is overly cautious, you can remove a specific warning with a comment before the offending line such as

  # shellcheck disable=SC1091
Also, take time to look through Greg's Wiki as it is possibly the best Bash resource that discusses the various pitfalls: https://mywiki.wooledge.org/BashPitfalls

As a Bash script writer, I disagree with your "red flag" interpretation as that'll mean that you'll end up with poorly written Bash scripts along with a hotch-potch of different tools to achieve the functionality (e.g. different versions of Python required for older scripts and newer ones). Knowing Bash is also very useful for writing Dockerfiles.

Post reply on HN