Hacker News Reader

Hacker News

Comment by don-code | Hacker News Reader

Full thread

don-code

For reasons like this, I almost wish software came with a "list of unexpected side-effects of using this software".

Take bash, for instance - each time you run a command (this list is nonexhaustive; I'd love to know others):

1. If you have a `PROMPT_COMMAND`, it'll be run.

2. The command will be echoed to your history file.

3. If you hit <TAB>, arbitrary functions might run (for completion).

I don't know what zsh may do on top of this, but my guess is that it's significantly more than bash. That's not a demerit to zsh - that's exactly what it should do - but visibility would be nice.

View on HN

> 2. The command will be echoed to your history file.

Important caveat: this goes into an in-memory history buffer; the history file is written when bash exits. This means that if you have multiple shells open, you will lose the history from all but the last shell to exit.

This is the default, but you can get around this behavior by writing to history immediately.

How do you do that?

Yes! If you want to maintain a full history (and you should!), you can make bash consistently log it:

    promptFunc() {
        # right before prompting for the next command, save the previous
        # command in a file.
        echo "$(date +%Y-%m-%d--%H-%M-%S) $(hostname) $PWD $(history 1)" \
          >> ~/.full_history
    }
    PROMPT_COMMAND=promptFunc

Instead of using that echo, you can tell bash to append the history:

    history -a

Setting the histappend option does the append thing on exit:

    shopt -s histappend

Instead of the ~/.full_history file you can just set your normal history to infinite:

    HISTFILESIZE=-1
    HISTSIZE=-1

Unfortunately, with this approach it only takes one invocation of bash without your .bashrc (or otherwise without HISTFILESIZE=-1) to truncate your history to 500 lines:

    $ man bash
    /HISTFILESIZE
         The  maximum number of lines contained in the history file.
         When this variable is assigned a value, the history file is
         truncated, if necessary, by removing the oldest entries, to
         contain no more than that number  of  lines.   The  default
         value  is  500.  The history file is also truncated to this
         size after writing it when an interactive shell exits.

(I also like that with my approach I also get the timestamp and current direct rate.)

It is for this reason that I also keep my bash history in git. I know other folks that do this too. There have also been solutions on HN in recent months for keeping your shell history in an sqlite database.

This will write duplicated entries to the file. Do you remove them on shell startup?

Since shell commands aren't necessarily (or even usually) idempotent, if I'm trying to figure out what I did earlier duplicate entries are still good to have.

The history will not be written if either the shell/OS crashes, or if you `unset HIST_FILE` before exiting the shell.

> or if you `unset HIST_FILE`

I figured I'd learn something by putting in the "I'd love to know others" bit, but this is something I didn't know I could do, and is genuinely useful to know!

Also, in most common cases, won’t be written to history file if the command is prefixed with a space (see HISTCONTROL).

You have a typo: it should be `HISTFILE`, not `HIST_FILE`.

No, it will append the newly run commands. Or at least on SUSE it does, maybe other distros configure it differently.

The .bash_history truncation feature of bash I find quite annoying

I am used to NetBSD's ash where I set HISTSIZE very high in .profile and save history with

   fc -l 0 > .history

With NetBSD I never "lose the history from all but the last shell to exit". I write history files when and where I want them written. (The irony is I am more likely to lose history if using bash, which auto-saves it, than I am when using ash, which does not. As GP suggests, bash is needlessly complicated.)

A large number of GNU/Linux use a fork of NetBSD's ash called dash. It is the installed default scripting shell on Debian, Ubuntu, etc. and the default shell in Busybox, OpenWRT, etc.

https://en.wikipedia.org//wiki/Dash_(shell)

Dash can be compiled with history support using libedit.^1 The static dash binary I use is 448k compiled with musl.

Dash is not as nice as NetBSD's ash for interactive use. For example, there's no tab completion in dash^2, hash -v does not work despite being listed in the manpage; there are various other small differences. In any event, I am using it as an interactive shell.

The Debian project decided dash is faster than bash as a scripting shell. For me, it is also faster as an interactive shell, because I am used to libedit and most of the interactive use I do is editing and running scripts/command line history

1. Instructions

   # install libedit - may already be installed for other programs such as openssh or sqlite
   wget https://git.kernel.org/pub/scm/utils/dash/dash.git/snapshot/dash-0.5.11.5.tar.gz
   tar xzf dash-0.5.11.5.tar.gz
   cd dash-0.5.11.5
   ./configure --with-libedit
   make
   cd src
   gcc -static -Wall -g -O2 -o dash alias.o arith_yacc.o arith_yylex.o cd.o error.o eval.o exec.o expand.o histedit.o input.o jobs.o mail.o main.o memalloc.o miscbltin.o mystring.o options.o parser.o redir.o show.o trap.o output.o bltin/printf.o system.o bltin/test.o bltin/times.o var.o builtins.o init.o nodes.o signames.o syntax.o -ledit -lcurses

2. Mostly I just use globbing instead. If I absolutely must have tab completion, I use tcsh. If I am not mistaken, tcsh was the first shell to offer that feature. I find it is the fastest of any shell when it comes to filename completion

s/tcsh was the first/& UNIX/

It took the command completion idea from TENEX and TOPS-20

For that matter, it would be nice if software with side effects of this sort disclosed them at runtime by default. For all its faults, this is something npm gets (partly) right. Partly, in this case, because it does print the commands it runs and their output, but it doesn’t tell you why.

I’m sure this would be overly verbose for most users, who would likely turn it off, but it would still be educational in terms of the huge set of implicit side effects normal every day software produces.

In Zsh setting '-x' on an interactive shell will also show you what is executed for prompts, completion, and any hooks (probably other things too)

same for bash

Reply on news.ycombinator.com