Live data from Hacker News

Mastering Bash and Terminal

blockloop.io

91–100 of 186 posts

Re: Mastering Bash and Terminal

#91

For changing directories, you can also use something like z ( https://github.com/rupa/z ) to jump around: Tracks your most used directories, based on 'frecency'. After a short learning phase, z will take you to the most 'frecent' directory that matches ALL of the regexes given on the command line, in order. For example, z foo bar would match /foo/bar but not /bar/foo.

I've been thinking about wanting something akin to this, I just had no idea it existed, so what I've been doing instead is I've defined short aliases for some of my most frequent directories. I use such an alias which I have named "no" which does "cd /var/www/no.nordstroem.www/pub/htdocs" on my Raspberry Pi where I host my website. For most directories on my laptop and desktop rather than using an alias even though I might have defined one is I first try a reverse search for it in the shell history, for example ^Rklon to get to ~/src/github.com/eriknstr/klondike/. However reverse search will fail whenever I haven't worked with a directory for a while or if I've been doing a lot of things in one directory since I have chosen to leave the length of the shell history at its default.

I would have liked to maybe start using the command you linked but unfortunately it is using the WTFPL so I will have to pass on it. But from the short description you quoted maybe I'll implement a similar tool myself some day. Then again maybe I will just keep doing things the way I'm doing them now because usually most of what I do is I go to a specific directory and do a lot of work there without moving much, typically said directory will be the root of the repository I have for what I'm working on. If I'm working in several project root directories at the same time I'll usually have multiple terminals open.

Re: Mastering Bash and Terminal

#92
post #82

In the spirit of sharing: one of my favorite lines in my bashrc is the alias of `rm` to `rm -i`. This prompts for a confirmation. You might not need it but I deleted some important, not-yet-checked-in-git files in the past by accident. If you want to delete everything and don't want to keep typing yes just do `yes | rm bla`.

No need to do that: just pass -f. The last flag "wins":

  $ rm -fi blah
  remove blah?
  $ rm -if blah
  $ # confirmation suppressed

Re: Mastering Bash and Terminal

#93
post #17

I recommend to install mc (Midnigth Commander) and bash-completion (if bash is your shell of choice) as first terminal tools. mc allows to explore system efficiently while not standing in my way, because I can always press ctrl-O and get my shell back. bash-completion saves time on typing of commands. Other tools I install often are htop (better ps) and strace.

all of these are my go-to tools. I also edit inputrc to make pgup and pgdn history search - something I picked up from SuSE version 15 years ago, and stuck.

would you mind to share and elaborate a bit. tq.

Re: Mastering Bash and Terminal

#94
post #55

Worth it just for finding out about `stty -ixon`. I never would have guessed from the `stty` man page description that this option would give me back C-s and C-q to bind to something actually useful.

It is described perfectly, but it does presume the reader knows the meaning of "XON/XOFF flow control".

Whether the reader knows that meaning immediately is a rather good proxy for just how long they have been working and/or playing with computers. Long ago, in a world of RS-232 connected display terminals and/or analog telephone modems, one became very familiar with "XON/XOFF flow control".

Re: Mastering Bash and Terminal

#95

bash (and shells in general) are so hacky (in a bad way) that I wouldn't want to waste my time mastering them. Whenever a shell script grows beyond 10 or 20 lines, I try to rewrite it in a "real" programming language. Fancy shell tricks are a code smell to me, and clarity and simplicity are of far greater importance. For me, as far as shells go it's usually enough to know the basics and be able to look stuff up when…

While I understand this sentiment, I think it's a point that needs a bit more thought; it's not a black and white issue.

On my personal machines, I often find places where I want to either clean up my desktop experience or automate some workflow, where I break some shell out. Most of the time, the overhead to drop into an actual programming language is quite heavy, and even though I try to comment my scripts and write them in a maintainable fashion, I only end up editing them maybe a few times a year.

I feel like discouraging shell scripts is part of what's driving us to seek increasingly heavyweight solutions like systemd in our architecture. Sometimes a lightweight environment where we trust the programmer is needed.

Re: Mastering Bash and Terminal

#97

Rather than temporarily suspend vim to use the terminal you can get vim to suspend and resume itself with the exclamation mark command. This has the benefit of not wreaking havoc on your vim session and allowing you to read data into vim by prefixing with r. For example :!ls will execute ls and show you the result (press enter to return) :r!ls will read the result of ls in for you More usefully :r!sed -n5,10p that/ot…

tmux is a good alternative to the whole paradigm of 'running shell commands within a text editor like vim'. Why run a shell command within vim when one can run the shell command in an actual shell? It seems to me that running a shell command in vim is using vim outside of its intended scope. It might be able to do it but it won't be able to do it well, which is where something like tmux comes in. I might be in the minority with this viewpoint though.

Re: Mastering Bash and Terminal

#98

I'm curious about the popularity of Bash vis a vis, say, Csh. Is Bash more popular due to superior features, or is simply because it is the default on quite a few *nix distros (and macOS)?

shell is a bit like JavaScript: both languages have a lot of warts, but if you interact with UNIX-like systems / browsers at intermediate or above levels, you must be comfortable with them. Unlike browsers, you have a few choices for shells, and IMHO [t]csh lost because a) Linux "won" over *BSDs, b) POSIX basically standardized on sh, c) [t]csh is a worse scripting language.

Back in uni I used to use tcsh interactively, script in [ba]sh, and program in a "real language" like C, Java, etc., but I wasn't doing anything very complicated with any of them. Once I started working and begin using these tools seriously, I simply couldn't learn and retain all of them. Something had to go, and tcsh was it.

Post reply on HN