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

61–70 of 341 posts

Re: Become Shell Literate

#61

Post by l3s2d »

mixmastamyk wrote: post #52
gfxgirl wrote: post #29

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

Opening a shell is not an obstacle when you've already got several open. Also, not all of us are refactoring huge codebases or using verbose languages that require a lot of handholding. The hard part of development is typically not at the typing or syntax levels, and I have the stdlib of my favorite libs close to memorized already. The most helpful ides tend to be massive as well. Tools can be useful however, such as…

It wasn't clear from your comment if you're aware of this, but Flutter hot-reload works from the command line too! I do all my Flutter development in 3 windows (vim, `flutter run` shell, android emulator).

Re: Become Shell Literate

#62

Post by mattmanser »

gfxgirl wrote: post #29

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

On top of that, his opening example is so easy if you use a GUI for Git it's mind-boggling.

It'd literally be click status column to sort, click top entry, shift-click bottom deleted file, right-click, restore. Done, a couple of seconds without even thinking about it.

And somehow this simple task in a GUI inspired a blog post about how useful the shell is.

I'm not going to deny a shell is extremely useful, and knowing far more than I do makes you a better programmer, but there's also using the right tool for the job.

Re: Become Shell Literate

#63

Post by combatentropy »

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…

You're right. I often think the man page should begin with a few examples, then launch into the neverending list of options.

That is no way to learn. In foreign language 101, they start you off with a small group of examples. "Como estas?" "Muy bien. Y tu?" Afterward, they explain the rules of the language (this is a noun, this is a verb, this is how you conjugate for first-person singular, etc.). In fact, this is how we learn our first language as babies. Anyone remember Mom and Dad pulling out a flip chart? Or did they just talk to you a lot?

The same goes with apprenticeships, I would think. The blacksmith starts the apprentice with simple tasks around the shop. I suppose he would intersperse it with the occasional pontification about principles and theory, but he would not sit down the pupil for weeks explaining everything before just letting him get his hands dirty.

The Linux man pages are upside down. Examples don't come till the very end, if at all.

Thankfully, like you said, there is now Stack Overflow.

Re: Become Shell Literate

#64

Post by dan-robertson »

There’s lots of powerful things you can do with a command line but I think it’s not that great an interface for the interactive run-look-modify loop one generally uses with writing shell commands.

Some commands are slow and caching their results can be a bit of a pain, if only because you need to use different syntax. Some commands shouldn’t be rerun as part of the cycle as they are side-effecting. Some commands can produce huge amounts of output which is annoying to deal with if you don’t think to run them into a pager. And sometimes certain kinds of data flow can be tricky to write (eg something like 1. List a bunch of things with a command, 2. For each thing pass it as an arg to a second command, 3. Print the result of that command next to the thing, where you want to write something like list-foo | tee /tmp/l | xargs -n1 query-foo | paste /tmp/l -, except this won’t work even if /tmp/l is a named pipe (it works if it’s a regular file and you add a | tac | tac after the tee)).

Finally, quoting is a bit of a horrific mess.

So here is a proposal for how I’d like a shell to work:

1. It still works as a shell so you can run ordinary commands.

2. By default all pipe operations don’t use a single Unix pipe but rather two pipes where data is transferred from one to the next by the shell (this can be done entirely in the kernel and very cheaply so long as you transfer in pages), and so you can see simple statistics (ie is anything happening), and optionally see some of the data going through

3. When you run a command, the output gets directed into something like a pager so it won’t make your history inaccessible, and furthermore, there’s a way to tack on a pipe into some other command on the end of your pipeline without it needing to rerun the earlier steps

4. Some commands like grep get interactive versions where you can see how the output varies live as you type in the arguments—there’s no need to keep readjusting your regex

5. Something a bit like awk or xargs as a first class feature of the shell language (and therefore some kind of notion of closure that builtin functions can use) to avoid some parts of quoting hell

Re: Become Shell Literate

#65

Post by chubot »

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…

Oil is making shell more sane, in a way that you can realistically adopt, since it runs existing shell scripts. See:

Four Features That Justify a New Unix Shell http://www.oilshell.org/blog/2020/10/osh-features.html

Re: Become Shell Literate

#67

Post by boogies »

mattmanser wrote: post #62
gfxgirl wrote: post #29

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

On top of that, his opening example is so easy if you use a GUI for Git it's mind-boggling. It'd literally be click status column to sort, click top entry, shift-click bottom deleted file, right-click, restore. Done, a couple of seconds without even thinking about it. And somehow this simple task in a GUI inspired a blog post about how useful the shell is. I'm not going to deny a shell is extremely useful, and knowin…

> Done, a couple of seconds without even thinking about it.

This was originally done in a couple of seconds without deeply thinking about it (hence originally using grep instead of `awk '/re/'`).

(Edit: quote)

Re: Become Shell Literate

#68

Post by chubot »

CJefferson wrote: post #15
Aloha wrote: post #12

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

Oil fixes this problem with QSN: http://www.oilshell.org/blog/2020/10/osh-features.html#safe-...

You can have newlines in filenames, but you can also pass binary data with \0 if you want (it's 8 bit clean). Or you can use read -0 for a NUL delimiter, and eventually length-prefixed blobs with netstrings.

The way I now think of it is that Oil should have all 3 solutions to "the framing problem" in networking: delimiting, escaping, and length prefixing. So you can convert from one regime to the other by using shell.

Re: Become Shell Literate

#69

Post by geophile »

theon144 wrote: post #20
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 wish that shell would be more sane. Absolutely agreed, shell is in many respects terrible. >I don't think that a shell should be a complete programming language. On the contrary, I think shell should be a more complete programming language! Drop the stringly typing and add actual types (hence eliminating 80% of bothersome awksedgrep magic; yes, no need to tell me it's a real tall order), add proper error handling…

Check out my pandemic project, marcel: https://marceltheshell.org. It hits that spot you described: still a shell, but more strongly typed. Instead of bailing out and redoing everything in Python (when you reach the end of your pipeline), you can add a bit of Python code in your command.

For example, find all the .py files under the current directory, find the ones that have changed in the last day, and then print the lines (with their filenames) that define classes:

    ls -fr \
    | select (f: f.suffix == '.py' and now() - f.mtime
read -l reads and labels a file, i.e., filename -> stream of (filename, line in file)

(Yes, this is doable with find and awk, but this is just an accessible example that gets across the idea of Python functions on the command line.)

Re: Become Shell Literate

#70

Post by yumaikas »

gfxgirl wrote: post #29

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

I'd also argue that it's helpful to understand the technology underlying your IDE, if only to be able to debug builds. (Understanding that MSBuild exists, and can be called from the command-line, for example, is a handy skill).
Post reply on HN