What was the point of [ “x$var” = “xval” ]?

     $ a=1; b=1; c='!'; d='!'
     $ [[ $a = $b && $c = $d ]] && echo true
     true

I would call it a bug when there's one valid way to read it, and [ fails to see it. I don't see the ambiguation. For example, zsh's [ doesn't have these errors:

  $ a=1; b=1; c='!'; d='!'
  $ [ "$a" = "$b" -a "$c" = "$d" ]; echo $?
  0
  $ [ '!' '(' "$c" = "$d" ')' ]; echo $?   
  1

I think bash's [ is just lacking the ability to backtrack while parsing its arguments.

Curiously, GNU's [ fails to parse the arguments of the first, but not the second's:

  $ command [ "$a" = "$b" -a "$c" = "$d" ]; echo $? 
  [: extra argument ‘!’
  2
  $ command [ '!' '(' "$c" = "$d" ')' ]; echo $?   
  1

  $ command [ "$a" = "$b" -a '(' "$c" = "$d" ')' ]; echo $? 
  0

Actually re-reading your post you probably know that already! Nevermind then. Maybe someone reading this will be enlightened

You know, shell scripts are a hack.

I really wish there was a middle ground between shell scripts and say python. Python has proper lists and hashes and loops and can manipulate paths with spaces or quotes or unicode. It doesn't get dragged down by the escape-an-escape-within-a-regex nonsense that makes things undecipherable. or ${VAR:-foo} or ${VAR##ugh}

But python is a bit fumbly when it comes to invoking external programs. try: ... subprocess.bleh except: ... ugh.

Perl may look ugly, but it doesn't have the escaping problems that Unix shells have. And most of the usual shell features (listing files, launching commands, etc...) are built-in. It is also available in almost all Unix systems, maybe even more so than bash.

My "favorite" (i.e. most terrifying) BASH fact is this: https://unix.stackexchange.com/questions/121013/how-does-lin...

Not suggesting it's suitable for everyone though. But it's certainly solved a lot of problems for me.

https://github.com/lmorg/murex

That’s how it used to be. Nowadays, most of the time it is a built-in, not it‘s own executable anymore.

So when test sees that one of its arguments is the string "-f", it has no way to know whether that string came from a variable like $var, a quoted string literal like "-f", or just the text -f. Most of the time if you're writing a parser for your own DSL you don't have this problem. You can tell the difference between the string literal "+" and the operator +.

They can be written in any compiled language you like or even an interpreted language, if you are prepared to add the dependency of an interpreter for that language at boot time.

This is a lot simpler than migrating to (and getting locked in to) systemd.

For all the vaunted Unix Philosophy it's amazing how clunky some of it is. Countless shell scripts still trip over spaces in filenames. Of those that don't, nearly all of them will still be confused by any unusual characters like newlines. If you want something done properly, you have to pull out a proper scripting language, to have readdir() and the ability to pass arguments directly to a process.

Even Perl, which generally excels in such tasks has weird lapses in convenience. You can run a command with one line of code without the possibility of confusion with `system("ls", "-l", $dir)`, but you can't get its output that way. There's no version of `system` that'd allow you to both explicitly specify each argument to the process, and obtain its output. You either use backticks and risk quoting trouble, or need to use `open`, which is a lot more verbose.

It's interesting that it took Microsoft to do a new approach in this regard. PowerShell has its amount of weirdness I really hate, such as that the environment escapes the program into the commandline, but it's really refreshing how it dispenses with brittle grep, awk and cut stuff.