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

191–200 of 341 posts

Re: Become Shell Literate

#191

Post by tommd »

spicyramen wrote: post #85

Our codebase uses tons of shellscripts and Python. Shell has been great for running installations tasks. Recently we added presubmits and added shellcheck utility to check for style and syntax. Any suggestions for adding unit tests for she'll scripts will be great. I'm planning to unify the syntax across the board

I love shellcheck. There's no great reason not to have any new shellcheck errors commented on each pull request. It's almost always right and how much you as the developer cares is the big question.

Re: Become Shell Literate

#192

Post by pulsapietro »

turbinerneiter wrote: post #130
vvanders wrote: post #120

Earlier quoted context omitted.

By framing the IDE as a crutch, that's very much in the gatekeeping category.

I didn't mean to frame the IDE as a crutch, I'm merely saying that you should try to not let it become a crutch aka. overly rely on it. I recently worked with a colleague who couldn't run the python program he wrote without the IDE. The IDE was not installed on the PC we were testing the program on. He is a better programmer than me. And I'm not saying "people who are using IDEs don't know anything". I'm literally on…

Don't worry - it was an completely fair comment but everything has to be so controversial in what has nowadays become the fashion industry, so it feels at times.

Re: Become Shell Literate

#193

Post by gnubison »

acabal wrote: post #49
boogies wrote: post #45

Earlier quoted context omitted.

(nit) > `grep --extended-regexp` but `sed --regexp-extended` Why not use `grep -E` and `sed -E`?

That's what I do on the command line (though I went so far as to just alias `grep` to `grep -E`), but when writing scripts I prefer to use expanded flags for clarity. When going back to a script one wrote a year ago, it's way easier to grok expanded flags instead of a bunch of single letters that have to be re-deciphered. (Especially with something like `grep` or `sed` that have 1,000 flags each.)

> Especially with something like `grep` or `sed` that have 1,000 flags each.

Sometimes I actually read the POSIX man pages instead of the standard ones — they are sometimes more useful because they have fewer features. Sometimes they are less useful because of their verbose language, though.

Re: Become Shell Literate

#194

Post by rakoo »

It still strikes me that after all this time, the next step in the direction of the author is to use an editor like ACME (https://en.wikipedia.org/wiki/Acme_(text_editor)): use the shell to its maximum power, where the output of a command can be edited and used to control the existing interface.

Take for instance this video: https://www.youtube.com/watch?v=4djoOiLste0 The author shows how the output of "git status" is just a text, you can modify the text and add "git add" just in front of the files you care about and add the file to the index. There is no linear loop of command input that becomes command output, it's all one big buffer that can feed itself. Consider how there could be another window that perpetually shows the status thanks to a combination of inotify and git status, and you have a git view. Fiddle with the command line argument and you can choose wether to show whitespaces or not, whether to show a summary view or the full diff, or restrict the list to some files. Have another window where you can write some message, and a GitCommit command in the "Tag" of the window will use the whole buffer as a git commit message; boom, you have 60% of what I use git-cola for.

A bit more information can be seen by one of its creator here: https://www.youtube.com/watch?v=dP1xVpMPn8M. The possibilities are truly endless, and I haven't seen anything that resembles it. There is just no editor that embraces your platform the way Acme does.

No, Emacs is not the same, because Emacs doesn't integrate with your OS; Emacs is an OS unto itself. You can't really say it's integrated to the OS when everything is implemented in the language that only Emacs uses.

Re: Become Shell Literate

#195

Post by patrec »

kaszanka wrote: post #167

That pipeline sure does look convenient. Let's see how it will handle a path with spaces. $ git status -s | grep '^ D' | awk '{ print $2 }' | xargs git checkout -- xargs: unmatched double quote; by default quotes are special to xargs unless you use the -0 option $ git status -s D "g h i" I'd be lying if I said I was surprised, to be honest.

Yeah, it's annoying that unix filenames and shell quoting are both fundamentally broken and that (as above) people would generally (knowingly) write a a broken-for-spaces-in-filenames version by default because it's easier (and the author no doubt knew he'd not encounter spaces in his repo). Having said that, it's not very hard to fix, I'd probably write something like:

    git status -s | awk -vORS="\0" 'gsub(/^ D /,"")' | xargs -0 git checkout --
Which is about the same length. This will still break for malicious input (newlines in filename), but for the original use case that's not a concern.

Re: Become Shell Literate

#196

Post by rjsw »

phkahler wrote: post #75
turbinerneiter wrote: post #47

Earlier quoted context omitted.

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.

I'm not really an IDE person but I find native Netbeans projects easier to understand than Maven ones.

Re: Become Shell Literate

#197

Post by dlivingston »

mraza007 wrote: post #100
turbinerneiter wrote: post #47

Earlier quoted context omitted.

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…

I didn’t really started out with IDE I become overwhelmed by using an IDE its just my personal preference but I love using text editor they are very simple and minimal

My understanding, as an exclusively nix developer, is that if you’re a Windows dev, all you really have are IDEs. Yes, I know about Cygwin and WSL and the rest, but if you’re a run of the mill Windows developer then your life is centered around Visual Studio and NetBeans and PyCharm and maybe Powershell and maybe maybe cmd.exe if you’re a greybeard.

That vim and bash and all of these terminal-driven ways of developing are the unique privilege (and I do say that unironically) of working with *nix systems.

That’s not to say Windows devs don’t use vim, but in my (limited) experience, it’s about as common as using a gas-powered generator to charge your Tesla.

Re: Become Shell Literate

#198

Post by boogies »

gnubison wrote: post #193
acabal wrote: post #49

Earlier quoted context omitted.

That's what I do on the command line (though I went so far as to just alias `grep` to `grep -E`), but when writing scripts I prefer to use expanded flags for clarity. When going back to a script one wrote a year ago, it's way easier to grok expanded flags instead of a bunch of single letters that have to be re-deciphered. (Especially with something like `grep` or `sed` that have 1,000 flags each.)

> Especially with something like `grep` or `sed` that have 1,000 flags each. Sometimes I actually read the POSIX man pages instead of the standard ones — they are sometimes more useful because they have fewer features. Sometimes they are less useful because of their verbose language, though.

> more useful because they have fewer features

That’s probably why DuckDuckGo’s `!man man`/manpage.me default to FreeBSD manpages. But if you really want something non-verbose you may prefer tldr.sh, cht.sh, or bro pages.

Re: Become Shell Literate

#199

Post by hiq »

xx789 wrote: post #176
tharne wrote: post #170

Earlier quoted context omitted.

> Bash has no repl, no unit tests not debugger Bash scripts are generally very short. If you need unit tests and a debugger you probably should be using something other than Bash. But saying you hate the shell because it's bad at something it was never designed for is silly.

At work I regularly have to support 500+ line scripts written by random developers, I 'n hate them.

Yeah I think that most people would hate this situation too compared to, say, similar scripts written in Python. But as parent said, the wrong tool for the wrong job is rarely a pleasant experience.

Re: Become Shell Literate

#200

Post by Closi »

dafoex wrote: post #41
Closi wrote: post #28

Earlier quoted context omitted.

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

Just suggested it in another comment, but Fish might be similar to what you describe. It has tab-completable flags that it gets from the manpages, and remembers and suggests previously run commands which might be close to the auto-complete you're after.

Fish is better, but it still only gets 1/10th of the way.

Why does terminal have to look like terminal? Like why is the 1980's ASCII telnet style the only way to do this?

The ASCII fish image on boot and fully ASCII menus only reinforces again that this isn't a modern interface, its an improved 1980's interface.

Why, for example, can autocomplete not look like this? https://code.visualstudio.com/docs/editor/intellisense

Why do progress bars when you are downloading from pip not look something like this? (still in-line with the terminal like a sparkline) https://docs.microsoft.com/en-us/windows/win32/uxguide/progr...

Like surely everything doesn't have to be SO 1980's if we want shell to stay relevant.

Post reply on HN