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

71–80 of 341 posts

Re: Become Shell Literate

#71

Post by jeddy3 »

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…

> The difference is like using a hammer vs using a nail gun.

I feel like this metaphor falls short.

The IDE, IMHO, is more like a multi-tool with pre-chosen use cases, but everything fits together nicely.

Using the shell is more like choosing the exact tools for the job, and maybe connecting them together in a make-shift fashion.

Re: Become Shell Literate

#72

Post by geophile »

geophile wrote: post #69
theon144 wrote: post #20

Earlier quoted context omitted.

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

Oh, and when you do bail out and go to Python, marcel's operators are available in a module (marcel.api), so that you can take your pipeline and move it into Python easily. E.g. here's the same example in Python:

    from marcel.api import *

    for path, line in (ls(file=True, recursive=True) |
                       select(lambda f: f.suffix == '.py' and 
                              now() - f.mtime

Re: Become Shell Literate

#74

Post by dan-robertson »

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…

That relies on there being a sufficiently versatile gui which isn’t guaranteed. Here’s some features that your example requires which I often don’t see in guis:

1. Tables you can sort

2. Tables you can sort on the thing you actually care about

3. Being able to select multiple entries and act on your selection

It’s not too hard to imagine criteria which could make the problem much harder for a gui, e.g. only doing the operation in a subdirectory (if the sorting is stable this isn’t so bad), or only on files not in a subdirectory (stable sorting won’t help here, you’d need the gui to let you eg search for / and then remove those things from your current selection), or only operating on .h files (you’d need a search->select feature again), or doing an operation that the gui doesn’t support on multiple files, or passing the list to some other tool (maybe you want to search makefiles for references to the deleted files).

Something that a gui may be able to handle but that often screws up shells would be file names with newlines or spaces in them.

Re: Become Shell Literate

#75

Post by phkahler »

turbinerneiter wrote: post #47
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…

Cool. Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE. Starting out, or only ever leaning an IDE is also hiding a lot of things from you. For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no…

>> Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE.

Yep. Another thing I hate is IDEs that build their own project files that tie you to them. A good IDE works with standard tooling, not as a replacement.

Re: Become Shell Literate

#76

Post by geophile »

thrower123 wrote: post #23
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.

About powershell's verbosity: My pandemic project is yet another pipe-objects-instead-of-strings shell, marcel: https://marceltheshell.org. It's "home" is Linux, not Windows.

Marcel is also somewhat verbose. It exposes Python functions on the command line, so when you need to write such a function, it starts getting long. E.g. if you want to sort files by last time modified:

    ls | sort (f: f.mtime)
There are abstraction mechanisms to help deal with this. E.g. this defines a command to sort piped-in files by time.

    bytime = [sort (f: f.mtime)]
So you can then do this:

    ls | bytime
Still kind of wordy. I'm thinking about a way of having flags expand to filters. That would get things as compact as bash.

Re: Become Shell Literate

#77

Post by bradwood »

jeffbee wrote: post #27
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

that's not a hack?! :)

Re: Become Shell Literate

#78

Post by turbinerneiter »

dan-robertson wrote: post #74
mattmanser wrote: post #62

Earlier quoted context omitted.

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…

That relies on there being a sufficiently versatile gui which isn’t guaranteed. Here’s some features that your example requires which I often don’t see in guis: 1. Tables you can sort 2. Tables you can sort on the thing you actually care about 3. Being able to select multiple entries and act on your selection It’s not too hard to imagine criteria which could make the problem much harder for a gui, e.g. only doing the…

In the end, your are gonna write regex either way :D

Re: Become Shell Literate

#79

Post by enriquto »

tutfbhuf wrote: post #51
enriquto wrote: post #9

Earlier quoted context omitted.

> I don't think that a shell should be a complete programming language. What do you mean exactly? If you have pipes and lists (e.g., the lines on a file) you are Turing-complete and people can and will make arbitrary programs. How would you like, precisely, to restrict the shell language so that it is not Turing-complete?

I mean shell should not be python, like xonsh. In my opinion it should not add programming language features (like types, futures, ADTs,...), but instead should clean up the existing built-ins + maybe little bit coreutils as built-ins.

Never heard about xonsh, it looks really cool. Seems like a step in the good direction (from python to shell). It needs a few steps more to attain the elegant perfection of the shell language, for example, removing this "type" stuff from the variables ;)

Re: Become Shell Literate

#80

Post by ddevault »

combatentropy wrote: post #63
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 ho…

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

You only learn the tool once. Every subsequent time you visit the man page, the information you're probably looking for is frontloaded. Just scroll to the bottom if you want examples?

Post reply on HN