4 ms·

So is it maybe that Python is a language with much smaller surface area and (most likely) much more consistent design, so we simply don't need a cheat sheet lik

by xixixao 13y ago

So is it maybe that Python is a language with much smaller surface area and (most likely) much more consistent design, so we simply don't need a cheat sheet like this? By rough estimate, my Mac came with over 1000 commands - no structure, namespacing. I love that xkcd. I really hope someone will take up the task of replacing the UI of *nix with something better. For me, it's like Windows 8: it was a nice idea to combine touch and traditional user interface - it just turns out to be inferior to either being done well. Writing shell scripts is just, let's face it, horrible, and the command line interface far from ideal. It works, it has for decades. But it's not like there has been a lot of competition to compare with. Sibling is complaining about academia and universities - but again, apart from sys admins, who don't teach, none of the academics know this stuff. Learning and teaching Python (Java) is in some respect easier but more importantly interesting - it just doesn't make sense to learn all these commands without actually needing them (whoever comes up with an exercise to use them all together gets a medal).

chadillac 13y ago
I agree with your sentiment but if you find the CLI to be a lack luster interface the only thing I can think is that you've not spent enough time using it correctly. I was a Windows guy, then an OS X guy, then a Linux guy. I found that I preferred CLI more than GUI's so I moved to Linux full time when I started getting frustrated with GUI tools and Darwin ports and the like. Now days it annoys me if a library doesn't have a CLI. Even on my personal machines I run the least amount of GUI possible for resource and usability purposes. I don't want a new GUI or a better CLI (zsh, csh, bash, ksh, etc. do just fine). I just want tools that utilize it properly to support it's most powerful functionality (pipes, output redirect, proper exit codes, etc.) A lack of familiarity with it is no institutes fault, it's a personal fault, if you find your self looking at a CLI interface, and then resorting to searching Google for a GUI wrapper for that interface, the ignorance isn't due to a failure of the CLI, it's a failure of the user being intimidated or ignorant. Also I have no issues writing shell scripts, I use them all the time to save me tons of work. If you're a programmer then you really get to know your system and you really get to customize it to your liking. An example would be switching to i3 from Gnome/KDE. I was a long time KDE/Gnome/XFCE user and my laptops track pad settings would never stick after a reboot when I used the GUI tools for disabling the touchpad tap to click or just disabling it in general (thinkpad nipples ftw). After moving to i3 and really getting more access to the core of the system I ended writing a couple little shell scripts for enabling disabling my touchpad for when I need/want it. What used to be a 5 step operation (open gui > click tab > uncheck box > click save) has now become (super+space, type disa[tab](autocomplete disable.touchpad), enter). I have a second script to enable it again, the contents of which are small. #!/bin/bash exec synclient TouchpadOff=1
- zodiac 13y ago
  I agree that CLIs are ofter better than GUIs, but I think the point was that the Linux CLI tools could have been designed better. For example, personally I don't like how gzip/gunzip comes in a pair, but there's no "untar" command, instead you must pass the -x argument to tar.
ecma 13y ago
I'd disagree with the assertion in your first paragraph. The Unix CLI toolset has evolved in a very similar way to any other software ecosystem. To compare with Python, the GNU coreutils/binutils and friends could be thought of as analagous to the Python core with other toolsets fulfilling a role similar to packages from PyPI. The standards and interface issues for both ecosystems are similar but luckily Python has more leeway to alter compatibility (ref changes in 3k). There are all sorts of issues with altering the nix toolset, and we mustn't forget the importance of POSIX for compatibility. We can't simply decide to 'replace the UI of *nix' without fundamentally changing how the nix ecosystem and community operate (and I wouldn't want to). OS development is not agile and rarely compat breaking, and for good reason. I also read the sibling as promoting a fundamental understanding of the underlying platform being developed on, not so much pushing teaching of just CLI usage. Knowing how, e.g., the filesystem works and the caveats involved is something that can lead to much better software design decisions. And knowing how to chain a cheap sed instead of just throwing Python and the re module at a glob.glob listing can be just as useful.

by xixixao 13y ago

chadillac 13y ago

I agree with your sentiment but if you find the CLI to be a lack luster interface the only thing I can think is that you've not spent enough time using it correctly. I was a Windows guy, then an OS X guy, then a Linux guy. I found that I preferred CLI more than GUI's so I moved to Linux full time when I started getting frustrated with GUI tools and Darwin ports and the like. Now days it annoys me if a library doesn't have a CLI. Even on my personal machines I run the least amount of GUI possible for resource and usability purposes. I don't want a new GUI or a better CLI (zsh, csh, bash, ksh, etc. do just fine). I just want tools that utilize it properly to support it's most powerful functionality (pipes, output redirect, proper exit codes, etc.) A lack of familiarity with it is no institutes fault, it's a personal fault, if you find your self looking at a CLI interface, and then resorting to searching Google for a GUI wrapper for that interface, the ignorance isn't due to a failure of the CLI, it's a failure of the user being intimidated or ignorant. Also I have no issues writing shell scripts, I use them all the time to save me tons of work. If you're a programmer then you really get to know your system and you really get to customize it to your liking. An example would be switching to i3 from Gnome/KDE. I was a long time KDE/Gnome/XFCE user and my laptops track pad settings would never stick after a reboot when I used the GUI tools for disabling the touchpad tap to click or just disabling it in general (thinkpad nipples ftw). After moving to i3 and really getting more access to the core of the system I ended writing a couple little shell scripts for enabling disabling my touchpad for when I need/want it. What used to be a 5 step operation (open gui > click tab > uncheck box > click save) has now become (super+space, type disa[tab](autocomplete disable.touchpad), enter). I have a second script to enable it again, the contents of which are small. #!/bin/bash exec synclient TouchpadOff=1

zodiac 13y ago
I agree that CLIs are ofter better than GUIs, but I think the point was that the Linux CLI tools could have been designed better. For example, personally I don't like how gzip/gunzip comes in a pair, but there's no "untar" command, instead you must pass the -x argument to tar.

ecma 13y ago

I'd disagree with the assertion in your first paragraph. The Unix CLI toolset has evolved in a very similar way to any other software ecosystem. To compare with Python, the GNU coreutils/binutils and friends could be thought of as analagous to the Python core with other toolsets fulfilling a role similar to packages from PyPI. The standards and interface issues for both ecosystems are similar but luckily Python has more leeway to alter compatibility (ref changes in 3k). There are all sorts of issues with altering the nix toolset, and we mustn't forget the importance of POSIX for compatibility. We can't simply decide to 'replace the UI of *nix' without fundamentally changing how the nix ecosystem and community operate (and I wouldn't want to). OS development is not agile and rarely compat breaking, and for good reason. I also read the sibling as promoting a fundamental understanding of the underlying platform being developed on, not so much pushing teaching of just CLI usage. Knowing how, e.g., the filesystem works and the caveats involved is something that can lead to much better software design decisions. And knowing how to chain a cheap sed instead of just throwing Python and the re module at a glob.glob listing can be just as useful.