Except that X11 isn't doing something so right -- it's still terrible, and it always has been, and we knew it was terrible at the time it was standardized.
But it's funny that you would bring up something as terrible as a shell scripting language like bash to compare to how terrible X-Windows is. Have you ever read through a gnu configure file yourself, or do you just close your eyes and type "./configure"? Who in their right mind would ever write a shell script, when there are so many real scripting languages that don't terribly suck universally available, that don't shit themselves when they encounter a file name with a space in it?
These quotes about X-Windows apply to bash as much as they do to X-Windows:
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski
"Programming X-Windows is like trying to find the square root of pi using roman numerals." -Unknown
That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome.
> Have you ever read through a gnu configure file yourself,
Yes. Generated scripts make for a boring read.
> or do you just close your eyes and type "./configure"?
I do, from people I chose to trust, whether by running the package build scripts written by the package maintainers of my distribution or from github accounts that I judge as trustworthy.
There is a lot of trust involved in using a computer. I mean, if something nefarious might be in the ./configure script, it's more likely to also be in a precompiled program, since more people touched it.
> Who in their right mind would ever write a shell script,
I do.
> when there are so many real scripting languages that don't terribly suck universally available,
Each language is good for different reasons. Shell languages are meant primarily to be used interactively, as opposed to languages like python or ruby. The fact that you can put your everyday interactions in a file and run that is an added bonus.
> that don't shit themselves when they encounter a file name with a space in it?
I rather not have filenames with spaces if it means having a language that allows me to communicate with my machine in a terse manner, allowing for super-easy automation of all sorts of interactions.
I mean, are you really suggesting to mandate quoting of all strings in a shell language? The quotes are optional. That's good! In a shell language, files are basically your variables, so why would you want more syntax around your variables when working interactively?
Oh god there's so many easy reasons why bash is terrible.
* Significant whitespace in surprising ways (a=1 vs a = 1 or spaces following square brackets)
* Word splitting
* No data structures of note, nor any way to create them in any sort of non-hacky way
* No data types, really, for that matter
* Can't really deal with binary data
* Awful error handling
* Weak math
* Weird scoping rules
Honestly as soon as I have to do anything that involves a conditional I abandon bash and use one of the many ubiquitous scripting languages that has great library support for doing all the system stuff you could do from the command line anyway.
Here's a great list of BASH pitfalls: https://mywiki.wooledge.org/BashPitfalls I can't think of any language other than maybe Perl or C++ that comes close to that
> * Significant whitespace in surprising ways (a=1 vs a = 1 or spaces following square brackets)
Variables in the shell are nicely coupled with environment variables. As a feature, you can do:
a=1 b=2 cmd
to concisely assign environment variables for a single command. How would you recommend that be redone? You'd need additional cumbersome syntax if you want whitespace to not be significant, and that sucks for a language meant to be used mostly interactively:
a = 1, b = 2: cmd
Because shell languages are meant primarily to be used interactively, we want to be very light on syntax. We don't want to have to say `var` or something before our variable definitions. We don't want to have more syntax than we absolutely need for our calls. Nothing like `cmd(a,b)`. cmd can be any string. They're just executable files in some directory. We want to include as many of them as possible, and their arguments can be anything, including `=`. Commands get as much freedom as possible over how they're called to fit as many needs as possible. So, how do you differentiate between calls and variable assignments?
Under those criteria, the current situation of statements being words separated by whitespace and the first words having `=` in them being assignments seems like the ideal solution.
> * Word splitting
Makes it easier to build commands without working syntax heavy complex data structures. Here's an example where word splitting is useful:
sudo strace -f $(printf " -p %s" $(pgrep sshd))
> * No data structures of note, nor any way to create them in any sort of non-hacky way
Complex data structure lead to more heavyweight syntax, and part of the appeal of shell languages is that everything is compatible with each other because everything is text. If you add data structures then not everything is text.
> * No data types, really, for that matter
Same point as above. Everything being text leads to increased compatibility. I wouldn't want to have to convert my data to pass it around.
That said, you could say that there are weak-typing semantics, since you can do `$(( $(cmd) + 2 ))`, for example.
> * Can't really deal with binary data
Because everything is text to encourage easily inspectable data exchange and compatibility between programs.
That said, while it's not advisable to do it, binary data is workable if you really need to do that. Pipes don't care. I can pipe music from ssh to ffmpeg to mpv, if I want. One just needs to be careful about doing text-things with it, like trying to pass it as a command argument. $() will remove a terminating newline if present, for example. That makes sense with text, but not with binary data.
> * Awful error handling
I don't get this. I think bash has very good error handling. Every command has a status code which is either no error or a specific error. Syntax like `while` and `if` work by looking at this status code. You can use `set -e` and subshells to get exception-like behavior. Warnings and error messages are, by default, excluded from being processed through pipes. What do you find lacking?
> * Weak math
Sure. I'll give you that bash doesn't support fractional numbers natively. zsh does support floating point.
> * Weird scoping rules
It's dynamic scoping, and it does have some advantages over the more commonly seen static scoping. You can use regular variables to setup execution environments of sorts. This somewhat relieves the need to pass around complex state between functions. It's kind of a different solution to the same problem that objects in OOP address.
The only problem is that static scoping became so popular that people now are generally not even aware that dynamic scoping exists or how to use it, so it's now not recommended to use it to not confuse people that don't know that part of the language they're using.
About that, I wish people would just learn more of the languages they use, and not expect every language to work the same, as they're not all meant for the same purposes or designed by the same criteria.
I think bash is fine as a shell and I understand why the syntax is the way it is, I'd just never use it for anything beyond a one liner or a list of commands. All my points were about its weaknesses for scripting, ie, anything that looks and acts like a program. There's basically no reason to use it that way when there are a million better programming languages that are ubiquitous and relatively small.
It still seems better suited when the script is mostly about running executables and passing their inputs and outputs between each other. As an example, I think `pass` was very nicely chosen to be done in bash. I don't think there would've been any benefit in doing it in a non-shell language.
I also think that if a program's job is by good proportion about sourcing shell-scripts to e.g. prepare an environment for them and/or manage their execution, it's also a good idea to make that program in the same shell language. As an example of this, I think Archlinux's `makepkg` was best done in bash.
On why make a program that's about sourcing shell scripts at all, the shell is the one common language all Unix-based OS users know in common, pretty much by definition, so it makes it a good candidate for things like the language of package description files. Besides the fact that software packaging of any language involves the shell, you kind of expect people that call directly on `makepkg` to also want to be able to edit these files, so making them in the language that they're most likely to know is good.
> That's a strong opinion. I'm not going to argue for lack of time, but suffice to say that 99% of my interactions with my computer and sometimes with my phone is with a shell scripting language. Shell scripting is awesome.
It really isn't though. (It certainly can be fun however). Switching from shell scripts, and avoiding to do things manually (like ssh), likely increases your success rate at managing *nix by orders of magnitude. All these "configuration management" tools like Puppet, Chef, SaltStack, Ansible etc. are pretty much just to avoid shell scripts and interactive ssh.
> All these "configuration management" tools like Puppet, Chef, SaltStack, Ansible etc. are pretty much just to avoid shell scripts and interactive ssh.
That's only true if your only use of the shell is for configuration, which isn't really intended to be the case. The shell was meant for any use of the computer, not just configuration. For example, I use ssh/scp when I copy some music files from my computer to my phone, or mpv when I want to play some music files. Indeed, I use the shell for nearly everything.
> Each language is good for different reasons. Shell languages are meant primarily to be used interactively, as opposed to languages like python or ruby. The fact that you can put your everyday interactions in a file and run that is an added bonus.
While UNIX was playing with sh, there were already platforms with REPLs, graphical displays and integrated debugger.
In fact Jupiter Notebooks are an approximation of that experience.
So give me a REPL with function composition and structured data, over pipes and parsing text for the nth time.
Thankfully PowerShell now works across all platforms that matter to me.
> Except that X11 isn't doing something so right -- it's still terrible
Yet your windows render and take input, life goes on, etc. I am pretty happy with it on systems where it runs. Some of the old criticisms like it being a resource hog - might have made sense in the specs of, say, 1993 or earlier, but even restricting the comparison to what most of us have loaded in Javascript at any moment it's pretty lightweight.
> Have you ever read through a gnu configure file yourself ... Who in their right mind would ever write a shell script
I really don't think it's fair to use machine-generated code as an example of why you shouldn't use a particular language. All of those alleged universally available, "real" scripting languages that don't terribly suck would also look pretty bad if you turned them into a target language for GNU autotools.
Shell scripting languages generally make certain common tasks easy that most other scripting languages do not. Namely, process management and especially piping information through those processes.
If that's most of what a program is doing I would 10000 times rather read a script written in bash doing it than a python script that pulls in 800 dependencies just to get halfway to making these sorts of tasks take less than 5 lines for each invocation of a thing that takes less than 1 line in bash.
That's not to say that bash is perfect, but it is very good at what it does.
Shell script also has dependencies: specific version of shell and CLI utilities. Shell script is a good thing when you need to write something quickly with hacks but it is not a good foundation for init system or build system. They easily break if you redefine variables like IFS, add command aliases or use names with spaces or special characters.
How do you for example parse command line arguments in your shell scripts?
Do you regard sed, grep and awk as dependencies when bash scripting?
With regards Python. The subprocess, os, sys etc modules are standard library modules. There is no dependency overhead in using them. Most smaller Python scripts manage very nicely with the standard library.
> Except that X11 isn't doing something so right -- it's still terrible, and it always has been, and we knew it was terrible at the time it was standardized.
And, yet, in ALL this time, not a single substitute arose?
We have multiple web browsers, GUI toolkits, IDE's, etc. all with far larger codebases and yet X11 never got replaced properly. And some really brilliant minds worked on it.
So the question you need to ask is "If X is so bad, WHY hasn't it been replaced?"
It has worked automaticlly for me for the last decade using different distros and the *BSDs. I do remember all that trouble though when I started experimenting with Linux/BSD in the early 2000s.
There are 2 things that cause this. Not having a driver installed and having it fall back to something which doesn't support the correct resolution or in fact bad cables.
Most user installs will not encounter either problem. New amd has great support out of the box without installing anything and many distros support installing closed source nvidia or will work well enough for non gaming applications with the open source drivers.
Please note that challenges aren't a result of X they are specifically the result of specific manufacturers drivers. Some of which have been more challenging in the past. For improvements on such in the future look to the manufacturers and support the ones that provide the optimal experience.
Please note issues where users can't set the correct resolution for their hardware ALSO occurs on windows 10.
How many distros will install e.g. the proprietary (i.e. covering most recent hardware) NVidia drivers out of the box? If I remember correctly, Ubuntu only just now started doing this.
You do need them if you want to use recent hardware, or get decent performance, or have working power management. From casual user's perspective, if this kind of stuff is not working properly, it's not really "set up".
Good point. Historically AMD/ATI didn't provide official support for hardware for anywhere near as long as Nvidia and the open source gpu driver didn't provide near the same performance. For example devices could be available as new retail units one year and unsupported less than 3 years later.
To contrast that nvidia generally provided support for a decade. For example the latest release only days ago supports hardware as old as 2012 legacy drivers support hardware as old as 2003.
This is why I have bought nvidia hardware despite other issues however it looks like AMD open source support will be better going forward. This doesn't help anyone with old hardware.
That's like asking "If Trump is so bad, WHY hasn't he been impeached?" Just because something's hard to remove, doesn't mean it's not doing something bad.
TBH, even humans shit themselves when they encounter monikers with spaces in them.
Can you spot the moniker with spaces in it in this sentence easily without having to go back and re-read? Without context, did I mean "moniker" or "moniker with spaces in it"?
On one hand, there are some things that are simply too complex to attempt implementation with bash a script.
otoh, there are many things that could or even ideally should be kept simple such that a bash script is the best practice, most simple, proven, reliable solution.
But it's funny that you would bring up something as terrible as a shell scripting language like bash to compare to how terrible X-Windows is. Have you ever read through a gnu configure file yourself, or do you just close your eyes and type "./configure"? Who in their right mind would ever write a shell script, when there are so many real scripting languages that don't terribly suck universally available, that don't shit themselves when they encounter a file name with a space in it?
These quotes about X-Windows apply to bash as much as they do to X-Windows:
"Using these toolkits is like trying to make a bookshelf out of mashed potatoes." -Jamie Zawinski
"Programming X-Windows is like trying to find the square root of pi using roman numerals." -Unknown
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...