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

181–190 of 191 posts

Re: A shell colon does nothing. Use it anyway

#181

Post by wpm »

orphereus wrote: post #40

I really hate bash because of its unreadable syntax, and this does not help it in any way. We have some large bash scripts in my company, ~10,000 LOC spread across multiple files, all sourcing each other and what not. It is truly hard to read bash, which means it is truly hard to maintain bash, which means that when the one person knowing the bash scripts in your company goes away, you're in for some "fun". My point…

Its not "unreadable" syntax, it's terse and unfamiliar. There are many languages with terse and unfamiliar syntax to me that I struggle to read, but only because I'm unfamiliar. In fact, most programming languages have unreadable syntax at first, save for maybe...AppleScript? Maybe Scratch. Even Python's famous readability isn't guaranteed, some of its functional programming facilities are just as arcane and unreadable as *sh.

I spend about 50% of time working time in the shell. I didn't find anything in TFA unreadable.

Re: A shell colon does nothing. Use it anyway

#182

Post by kazinator »

refp wrote: post #34
kazinator wrote: post #25

> ( : The subshell execution parentheses and the colon are superfluous here, just: Redirections do not require a colon command to hang off of, and there is no need to fork a subshell to execute such a command. > ( : >> result.json ) && echo YES # is result.json writable? As a go-to idiom for a writability test, it gives me pause. If the file didn't exist, we created a zero-length one. That might be okay if we are goi…

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…

> : This is required by POSIX in the section "Consequences of Shell Errors". If a redirection error occurs in a special built-in command, a non-interactive shell is required to exit.

The bare redirection without : does not have this problem:
Therefore, in a POSIX-conforming shell, we do not need to wrap it in a subshell.

> but your message is factually wrong - on so many levels.

How many? Can you count the levels? I didn't know that in zsh "< file" dumps to standard output, which is suppressed by :. If I used Zsh, I would know that sort of thing.

Re: A shell colon does nothing. Use it anyway

#183

Post by ButlerianJihad »

Linux-Fan wrote: post #131
mqus wrote: post #112

Is : the same as `true` ?

I was asking myself the same question and looked it up: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/t... > The most important differences seem to be: * `:` is a builtin vs. `true` is an utility * passing arguments to `:` is safe but for `true` its not hence `:` is the right thing to use here.

In the Bash shell, true is a builtin. It may be a builtin for other POSIX-compliant shells. false is also a builtin.

The key difference is that : is required to be builtin. There are several good reasons for this. For example, syntax: the shell can single out this special character syntactically before searching $PATH.

Also, ":" is a disallowed or problematic character for certain filesystem types. If your shell attempted to omit this builtin, it could not always rely on an external command file by this name.

Lastly, people keep bringing up fish, but it is not a POSIX shell, so its similarities in syntax and operation are coincidental.

Re: A shell colon does nothing. Use it anyway

#184

Post by brabel »

lucideer wrote: post #85
brabel wrote: post #47

Earlier quoted context omitted.

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

Everyone says "brevity makes things unreadable" but when given the choice to write a one liner bash script VS a 10 line Python/JS/Ruby script we all know which people always choose.

Re: A shell colon does nothing. Use it anyway

#185

Post by crabbone »

garethrowlands wrote: post #102
crabbone wrote: post #67

Earlier quoted context omitted.

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…

> System shell, however, isn't meant for writing entire applications. Programmable shells are, in fact, for programming. That posix shell syntax makes it impractical for meaningfully large scripts is something you just accept. And, realistically, it is something you have to accept. Minimalism isn't why posix shell syntax is bad. For example, awk and jq are minimal but don't make the same mistakes. Powershell was neve…

There are many programs that aren't applications. For example, databases. You wouldn't argue that because you can program in eg. SQL it should be able to make applications with a robust command-line interface, right? Same idea applies to system Shell. Its purpose is to expose the operating system functionality interactively and for ad hoc automation. It is deliberately made simple and therefore incapable of more advanced system programming because complexity creates problems in this particular domain.

For instance, consider that Unix Shell only has one data-type: strings. I believe this was a deliberate decision by its creators (or a stroke of luck). Compare this to languages s.a. original JavaScript with a handful of built-in types, or, even worse, modern JavaScript with user-defined types. Even though the language tries hard to supply default "solutions" to type mismatch errors, it doesn't work well, and sometimes, at all. Unix Shell is inherently incapable of type errors.

While in statically checked programs, or even dynamically checked ones with robust debugging tools types could prevent certain kinds of programming errors, in the mostly interactive programs types make no sense. There simply isn't enough code to generate the kinds of problems types are supposed to solve.

> Minimalism isn't why posix shell syntax is bad.

I never said that.

> Powershell was never designed to be your system shell

Parent wants to replace Linux system shell with PowerShell, that was the reason I replied in the way I did.

Re: A shell colon does nothing. Use it anyway

#186

Post by crabbone »

IdiotSavage wrote: post #128
crabbone wrote: post #67

Earlier quoted context omitted.

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…

No, I didn't imply that. PowerShell introduces many different error modes that aren't possible in Unix Shell because it tries to operate on structured messages, has a type system, has a bunch of built-in functionality for accessing various aspects of the system that in Unix Shell are delegated to external utilities.

Re: A shell colon does nothing. Use it anyway

#188

Post by nomel »

_bernd wrote: post #61
nomel wrote: post #28

Earlier quoted context omitted.

Bash scripts requires "set -eu" at minimum, when written by LLM or human. It's the only language terrible enough to make the default behavior ignore undefined variables, commands, and execution errors, and happily continue executing whatever was produced by me smashing my hands on the keyboard, until the end of the file, while returning an exit code of 0, claiming complete success.

> Bash scripts requires "set -eu" at minimum, when written by LLM or human. No. It does not. Just write good scripts and catch errors and handle them. That's the same more less with every language. And bash can be written in a way that it is sane and readable and maintainable. Just because you have seen a lot of junk in the language does not make the language bad per se. Sure there are a lot of languages "features" w…

I agree completely, if you use a linter like shellcheck [1]. If you're just winging it, then no.

I first learned about shellcehck when I worked with someone that claimed they could write flawless bash scripts, then blamed me when their script broke because there was a space in a folder name. I ran his scripts through, resulting in him immediately adopting it, while he enjoyed eating crow.

[1] https://www.shellcheck.net

Re: A shell colon does nothing. Use it anyway

#189

Post by _bernd »

nomel wrote: post #188
_bernd wrote: post #61

Earlier quoted context omitted.

> Bash scripts requires "set -eu" at minimum, when written by LLM or human. No. It does not. Just write good scripts and catch errors and handle them. That's the same more less with every language. And bash can be written in a way that it is sane and readable and maintainable. Just because you have seen a lot of junk in the language does not make the language bad per se. Sure there are a lot of languages "features" w…

I agree completely, if you use a linter like shellcheck [1]. If you're just winging it, then no. I first learned about shellcehck when I worked with someone that claimed they could write flawless bash scripts, then blamed me when their script broke because there was a space in a folder name. I ran his scripts through, resulting in him immediately adopting it, while he enjoyed eating crow. [1] https://www.shellcheck.n…

Yes :) I'm using shellcheck since at least 2012/2014. And I loved the bash haters handbook <3 in all seriousness, bash will shine then when you have no heavy tooling available and we still have these systems around as at least at some point in time in their life time. With most stuff in life: you should take care and pay attention

Re: A shell colon does nothing. Use it anyway

#190

Post by nomel »

_bernd wrote: post #189
nomel wrote: post #188

Earlier quoted context omitted.

I agree completely, if you use a linter like shellcheck [1]. If you're just winging it, then no. I first learned about shellcehck when I worked with someone that claimed they could write flawless bash scripts, then blamed me when their script broke because there was a space in a folder name. I ran his scripts through, resulting in him immediately adopting it, while he enjoyed eating crow. [1] https://www.shellcheck.n…

Yes :) I'm using shellcheck since at least 2012/2014. And I loved the bash haters handbook <3 in all seriousness, bash will shine then when you have no heavy tooling available and we still have these systems around as at least at some point in time in their life time. With most stuff in life: you should take care and pay attention

Then, I think we fully align. Yes, shell scripts aren't going anywhere, and are pretty great. I usually write several per week. I just make sure to enable eu, and also have error traps, with little error messages, because I hate heisencode more than anything.

But, you'll never convince me that "ignore errors by default" is sane. ;)

Post reply on HN