Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Become Shell Literate

drewdevault.com

Post reply on HN
Print view View original

21–30 of 341 posts

Re: Become Shell Literate

#21

Post by masklinn »

thakoppno wrote: post #11

that one tip about using touch to modify the video file metadata resonated with me. at the same time, it is a bit of a hack. what is the minimal non-hack version of this technique? seems abstractly like liking a file-descriptor. thanks for the article. it reminds to get better at awk.

> at the same time, it is a bit of a hack. what is the minimal non-hack version of this technique? seems abstractly like liking a file-descriptor.

Using a "proper" media manager and adding the file to a play queue?

Re: Become Shell Literate

#22

Post by enriquto »

ddevault wrote: post #13

Author here! Some extra tips for HN: If you dislike POSIX sh, consider looking at Plan 9's rc before you look anywhere else (including bash): http://man.9front.org/1/rc Also, I would advise you to learn about these four tools in depth: sh, sed, awk, and make. Learn when to use each, and don't use one when another would be better.

Thanks for writing this! I enjoyed this article.

The "make" tool is really powerful, besides its use for calling compilers. You can write really nifty scripts with make that have automatically optimal parallel scheduling.

Re: Become Shell Literate

#23

Post by thrower123 »

tutfbhuf wrote: post #4

I wish that shell would be more sane. I don't think that a shell should be a complete programming language. If you need a programming language, then better use one. There is xonsh if you are looking for something like this. I think there should be a better bash with an very clean and consistent interface. Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the b…

If you think the unix shell sucks, try fucking around with the Windows shell - either of them. You're either in a world of legacy and inconsistency dating to DOS and the days of 8.3 filenames, or you're in the also wildly inconsistent, but very verbose, world of PowersHell.

Re: Become Shell Literate

#24

Post by chubot »

mooreds wrote: post #5

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

Yeah the way I think of this is that some people write a text or Markdown file with shell commands for documentation.

I INVERT this, and write a shell script with comments :) That way someone else can reuse your knowledge more easily (and your future self as well).

Examples:

Constructing a big curl command to use the Zulip API, and also using jq for the first time. I used this to easily make a blog post out of a long Zulip thread [1]

https://github.com/oilshell/oil/blob/master/services/zulip.s... (oops some tabs snuck in here)

Figuring out how to use uftrace (and successfully optimizing Oil with it [2]):

https://github.com/oilshell/oil/blob/master/benchmarks/uftra...

Though one issue is that shell scripts don't really specify their environment, but there is a large number of tools growing around containers that can solve this problem. (Basically Docker is being refactored into something more sane; thank you to OCI and others.)

So I hope to integrate the Oil shell and containers more so shell scripts are more reproducible. I mean most of the container tools are already command line tools so in some sense it's already done, but you can imagine closer integration (e.g. not just passing code as text from outside the container to inside the container).

----

I wrote some notes about the documentation issue here: http://www.oilshell.org/blog/2020/02/good-parts-sketch.html#...

And one thing I've wondered is if Oil should literally run shell out of markdown, so you can create executable docs. I can see it being useful, but it might be something you should do with a separate tool that converts markdown code blocks to a shell script...

[1] http://www.oilshell.org/blog/2020/11/more-syntax.html

[2] http://www.oilshell.org/blog/2020/01/parser-benchmarks.html

Re: Become Shell Literate

#25

Post by rootlocus »

jancsika wrote: post #18

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

> 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.

You might enjoy https://cheat.sh which is usable via curl: `curl cheat.sh/grep`

Re: Become Shell Literate

#26

Post by acabal »

jancsika wrote: post #18

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

The inconsistency sometimes bothers me too, but it makes me feel a little better to remember that so many of the CLI commands we take for granted are part of an old historical heritage. The inconsistency is part of that heritage--today's CLI wasn't designed all at once by one group, but rather evolved over 50+ years from many contributors, back when nobody expected that people would still be using `sed` in 2020.

For me, reflecting on that history helps dull the annoyance of having to type `grep --extended-regexp` but `sed --regexp-extended`.

Re: Become Shell Literate

#27

Post by jeffbee »

thakoppno wrote: post #11

that one tip about using touch to modify the video file metadata resonated with me. at the same time, it is a bit of a hack. what is the minimal non-hack version of this technique? seems abstractly like liking a file-descriptor. thanks for the article. it reminds to get better at awk.

> what is the minimal non-hack version of this technique

Rename the file 00WATCHME

Re: Become Shell Literate

#28

Post by Closi »

tutfbhuf wrote: post #4

I wish that shell would be more sane. I don't think that a shell should be a complete programming language. If you need a programming language, then better use one. There is xonsh if you are looking for something like this. I think there should be a better bash with an very clean and consistent interface. Some of the most commonly used utils like awk '{ print $2}', sed, grep, sort, ... should be included out of the b…

> I think there should be a better bash with an very clean and consistent interface.

Absolutely! Some work should be put into making it way more intuitive. Having to remember what every flag means (which is different in every app!) is not intuitive at all.

By default there should be some sort of intelisense auto-complete which can also provide guidance on what on earth all the flags mean, and maybe eventually it could tell you what it expects to do before you run the command. For most users otherwise it ends up being "paste in this command you googled with a load of random flags you don't understand and won't remember"

Re: Become Shell Literate

#29

Post by gfxgirl »

Someone should write "become IDE literate" as a response to opening of using vim with no extensions and using grep a lot.

I've been using editors that are language aware since at least the late 90s. Depending on the language they'll show me all references, take me to the definition or declaration, stack those jumps so as I follow the links I can pop back a level to where I was. All of this is instant. 1000x faster than opening a shell and trying to grep all the project files for word phrases which, not being language aware, can't tell if one 'foo' is relevant or irrelevant from another 'foo'. They'll also let me refactor various things from renaming a method/class/variable/function and correctly fixing all the related files to doing things like changing class members to getter/setters and other things.

The difference is like using a hammer vs using a nail gun. There are times where they hammer is useful but given the job of constructing a building a nail gun will get the job done much faster.

Re: Become Shell Literate

#30

Post by CJefferson »

enriquto wrote: post #17
CJefferson wrote: post #15

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

This would require filenames became valid utf-8. This would be a good thing to do nowadays, irritatingly (having tried handling Unix filenames as utf 8 in the past), surprisingly many users have non-utf8 filenames.
Post reply on HN