I find shell literacy more important than ever as I continue to invest in CI/CD using GitHub actions.
With multiple contexts, and sometimes complex behavior, leveraging shell seems key to debug and gluing things together.
Become Shell Literate
31–40 of 341 posts
Re: Become Shell Literate
#32cpio is the better tool for the job in the last example, compared to tar. You don't have to use xargs, for one. It's safer to use `find -0 | cpio -0o` because it can handle weird filenames that contain newlines or other spaces.
File names that contain newlines??
Re: Become Shell Literate
#33Hear hear! I remember a senior dev at my first job being stymied by the command line; he was very adept in the IDE, but had a hard time navigating directories. It was definitely a disadvantage when it came to getting stuff done. One thing the author didn't cover is how you can share reified knowledge when you write shell scripts. (It's the same with other programming languages, but they aren't as easy to write or mod…
yes, you're absolutely spot on - I'm part of a remote team and we made it mission to try and just use shell-commands to communicating business-centric admin stuff, such as: add this row in the table, modify this stored parameter, invoke that api call via curl, etc. They're all shorter than 10 lines usually but help illustrate exactly what needs to happen with very little room for interpretation.
Re: Become Shell Literate
#34I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
I recommend https://tldr.sh/. Since I installed `tldr`, I rarely read the man pages.
Re: Become Shell Literate
#35I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
tldr [0] is great for easy to understand example commands. It is community driven and there are many cli based programs you can install[1][2].
[0] https://tldr.sh/
Re: Become Shell Literate
#36I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
Using Fish as my shell somewhat makes this morn tolerable as it checks the manpages and automatically suggests flags in a tab-complete fashion. It also remembers previously run commands and suggests them, which helps with not having to remember exactly which flag does what, because the example comes from the last time you ran the command.
Re: Become Shell Literate
#37Learning the shell was one of the best things I did as a programmer.
It helped a lot that 15+ years ago I committed to running desktop Linux as a daily driver. Especially back then when things were much rougher on the desktop, using Linux as a daily driver means occasionally doing something in the shell.
Ultimately, just like learning a programming language, one must have a practical reason, a project, to make it worth the while to learn as you go. For someone interested in learning to use the power of the shell, don't just go read a book or do some exercises or tape a cheat sheet to the wall. Instead, commit to using it for daily tasks for a month, or for maintaining a project entirely in the shell, not even using a GUI file manager. It's tough at first but so worth it!
Re: Become Shell Literate
#38I find shell literacy more important than ever as I continue to invest in CI/CD using GitHub actions. With multiple contexts, and sometimes complex behavior, leveraging shell seems key to debug and gluing things together.
Yup, it seems that shell embedded in YAML is pretty much a pattern now (Github Actions, Gitlab, Kubenetes, Travis CI, sourcehut, etc.)
And I think it's growing beyond CI/CD -- that is, Github actions is a more general platform than Travis CI, etc.
Good example: https://lobste.rs/s/oeelem/using_github_issues_as_hugo_front...
My pet peeve is that YAML is a terrible syntax for a shell script, i.e. there are if statements in a weird YAML DSL in addition to if statements in shell (which people already complain is hard to remember)
People complain about shell syntax, but YAML is even worse.
So I would like to make Oil a better language for specifying these "distributed shell scripts":
Re: Become Shell Literate
#39Earlier quoted context omitted.
One of the best things (in my opinion) shells could have done is do newline separated filenames instead of spaces, which would make filenames with spaces much easier to handle (you can have newlines in filenames, but in this magic world let's ban those).
That would pose problems also. The real solution, with no need to magic as you say, is to disallow spaces at the filesystem level (just like slashes and the null character are forbidden). For users typing filenames, this shouldn't be a problem, as those can be encoded e.g., as unicode's non-breaking space. Using space as a separator is a very important power, that other programming languages share. In what other prog…
> In what other programming language can you put spaces in variable names?
PowerShell; although you have to use long form to do it:
PS C:\> ${var with spaces} = 1
PS C:\> Get-Variable *space*
Name Value
---- -----
var with spaces 1
PS C:\> ${var with spaces} + 2
3Re: Become Shell Literate
#40Earlier quoted context omitted.
It wouldn't be coherently unixy if it was. Small tools that do a limited subset of things, and reliably take/output data from stdin/stdout is the way unix is done. sh is just the glue we use to tack it all together. Bash (and other shells too) is like it is, because it's an accretion of 50 years of history rather than a singular top down design.
One of the best things (in my opinion) shells could have done is do newline separated filenames instead of spaces, which would make filenames with spaces much easier to handle (you can have newlines in filenames, but in this magic world let's ban those).
I don't see a functional difference in denying spaces in paths from denying new lines in paths.
My dream OS would forbid path names that don't match \w in grep.