Hacker News Reader

Comment by skydhash | Hacker News Reader

For personal workstation, the current directory is enough. Maybe I change the color based the status of the last command. That’s pretty much the only information I need before entering any command. Everything else can be accessed when I really need it.

View on HN

You don't need to know what branch you're on before running commands? I cant tell you the number of times ive been on the wrong branch executing stuff.

For me the AWS integration is nice. That way I know what account I'm on, and what region among my dozens of windows.

For example:

    …/.config master on AWS_Prod (use2)

starship.toml:

    [aws]
    format = 'on [($profile )(\($region\) )]($style)'
    style = 'bold #B23D2F'
    symbol = " "  <- cloud symbol
    [aws.region_aliases]
    us-east-1 = 'use1'
    us-east-2 = 'use2'

Oh ya, for work the kubeconfig integration is absolutely essential, i bounce between local clusters and shared nonprod clusters all the time and while its not an outage to break the nonprods its going to annoy a lot of people so its nice to know which one is active.

I literally use just PS1='$ '.

`git status` to know git stuff. `pwd` for the current working directory, etc

I also don't use aliases like `gs` or `..`

One good thing about having a very minimal setup is that you feel at home anywhere.

It wasn't always like this. I used many, many prompts and shell tools over the decades. The only tool that stood the test of time is tmux.

Same here. I definitely went through a powerline, alias, huge vimrc, etc phase, but it turns out just sticking to the base toolset is pretty handy.

I can sit down at (or ssh into) any machine and be basically just as productive, and it also turns out that I just always want to know more than nicely fits into the prompt anyways.

There's something to be said for accepting the defaults of a tool, and learning to use them well. Customization is powerful, but... I think most times it's not the right call until you're already an expert in the tool at hand.

Same here, I also find that aliases for speed introduce unnecessary complexity and mental overhead later on. It's not much, and for other people it doesn't matter or they have a different preference, but that's what I prefer.

Sort of contrary to that I really enjoy the maximalist shells. A computer should be fun to use!

I don't use aliases, but abbreviations that expand to the actual full command. Helpful to type less and history has the exact.

I like this. What do you use to accomplish this?

I don’t know exactly what they’re referencing, but Zsh has something like that where you can expand eg filenames and paths from this unique bits.

So if you have

``` src/components/Button.vue src/components/ButtonGroup.vue ```

And you type `nvim s/c/G<Tab>` it’ll expand to the second file’s path.

See when I don't have a prompt I forget to run those things and just autopilot through a lot of commands before I realize Im on the wrong branch.

For example if I have say 3 worktrees open in 3 seperate tmux tabs and are context switching between them (very common when reviewing multiple PRs from my devs) Sometimes i will get the tabs mixed up, which worktree is where etc and just autopilot a bunch of commands meant for one tree into a different one and its quite annoying to clean up.

The prompt has generally stopped me from doing that.

On tmux, I use split panels more often than tabs.

Usually, there will be from 2 to 8 panels of different sizes.

This gives me spacial short term memory: I know what each shell is by the panel position.

I can zoom on then to bring them full screen (ctrl+b z) if I'm going to do anything that requires more space, then zoom out to the panel arrangement when I'm done.

Sometimes I'll name prompts (eg `PS1='stg$ '`), specially when working with ssh, but that's rare.

What inspired me to work this way was this video on the acme editor: https://www.youtube.com/watch?v=dP1xVpMPn8M

"The only tool that stood the test of time is tmux."

tmux comes from BSD rather thsn GNU/Linux, or Windows

What is the default shell in OpenBSD

starship does not support it

   starship init ksh

   ksh is not yet supported by starship.
   For the time being, we support the following shells:
   * bash
   * elvish
   * fish
   * ion
   * powershell
   * tcsh
   * zsh
   * nu
   * xonsh
   * cmd

   Please open an issue in the starship repo if you would like to see support for ksh:
   https://github.com/starship/starship/issues/new

I just run git status manually, I always explicitly specify the branch when I do anything that touches a remote, everything else you can undo if you have to.

I'm highly aware of which branch I'm on. Because it's because I don't use any scripts or automation that switches branches; I only ever switch branches manually so I have that awareness.

I only switch branches manually too, but I work in many repos and come back to stuff after days sometimes.

Even if I know my current branch, having my prompt show me untracked/uncommitted/unpushed changes helps to identify if something didn’t work because I’m in a dirty state, or if something I ran (unexpectedly) caused a dirty state.

For example, I don’t expect running scripts/build.sh to modify tracked files in the repo. Seeing part of the prompt go from “” to “?2!3” (two untracked, three changed files) makes that glaringly obvious.

"git status" is all you need then.

Then you have to remember to run this regularly. Which i regularly forget in tmux autopilot mode. The prompt serves as one last headsup reminder. Even then sometimes I dont look at it and have to roll some stuff back

How well does this work when you work on multiple repos with longer pauses inbetween?

And the Branch is also an unintrusive reminder that you are in a path under versioncontrol.

not op, but if I haven’t been in a working directory for a while, I always run `git status` anyway. Then I know the branch and any out of date files. I usually run `git pull —-rebase` and get everything back up to date. I try not to leave broken branches around, so It’s rare that knowing which branch I’m on is an issue.

oh-my-zsh default prompt mode for git branches is for me! super clean. need to familiarize myself with some more of their shorthand commands.

As a complete aside, and not to argue with you at all: I think it might change your life to take a good look at jj. I just mention this to try to be helpful to you.

Manual git status is enough for me.

I guess it depends on your day job and workflow?

I’m a researcher and work on small projects with 1-3 people (most of the time it’s just me prototyping stuff alone). I then tend to work on a branch for weeks at a time, so the git branch provides very little information compared to the space it takes in a prompt.

If I was switching branches every 5min, it would be useful.

I like stuffing everything which might be important to the context window in there, personally. Saving 50ms on the prompt load sure beats a false negative when something goes wrong because I don't even think to ask whether I have the wrong Node version installed or something.

When starting to work on something, I generally do a sanity check to see that the fundamentals are there and correct versions, then throw that part of the context out of mind, knowing that I stand on firm ground.

I found out that with this verify-and-forget step, I work much more efficiently.

As a result, my workflow becomes independent of the machine I work on, because I become the tool, not my setup. After that point, only having a "$" at the beginning of the line is enough.

Of course everyone have their own choices, and YMMV.

Yes. I show the python or node version of currently active venv and venv name.

Also, I somehow worked in special characters for Python and other things that get screwed up if I don’t have the right nerd font installed on the system.

How often are you switching these things that you need their values in sight at all times though?

Even for cases where I need to use old versions, I don’t need a reminder of that every time I run a command.

All of the time. Often I'm working with 3-4 different project contexts simultaneously.

It isn't that useful but I do glance it when I'm working on dependencies and to ensure the context between a terminal session and pycharm's interpreter match.

The information doesn't cloud the prompt for me though, as it is right justified and I don't really think about time to load, as the machines are relatively recent Apple Silicon.

Problem is you can't get timestamps and run times of your commands 'when you really need it', unlike almost everything else

Why the timestamps are that important? Honestly asking.

You can always time your commands with "time".

I personally use a modified zbell (in zsh) to give me a notification when a command finishes after 30 seconds, and send me an email if it takes over 2 minutes.

I generally use Konsole's "notify when program exits" feature. For longer tasks, I have a small tool which I pipe to, and it sends me push notification with the output (if I prefer).

I had a tool I'd pipe to, but I'd often only think about it after I'd realize that the command was going to take a while. A push notification sound cool; I used email because I knew how to hack it together with curl.

Here's one zbell implementation, not sure it's the original but it looks like it does the trick: https://gist.github.com/oknowton/8346801

Thanks for sharing the bell. I'll take a look. If you want to try push notifications, I use https://pushover.net as a service.

I developed the tool myself, and it's at https://git.sr.ht/~bayindirh/nudge if you feel like checking it out.

If you want to host the whole push notification infrastructure, you can look at https://ntfy.sh which also can be integrated with cURL.

This is incredibly helpful, thank you. I had no idea push notifications was something I could self-host.

You're absolutely welcome. Me neither. If I could find ntfy.sh earlier, I'd have written nudge for it, not for Pushover.

When you’re debugging, especially a complex system, especially during an outage or postmortem, understanding when your commands executed relative to when your log lines appeared is really helpful.

Oh, that's an interesting use case, alright.

sounds like your describing https://linux.die.net/man/1/ts

That's a poor and hacky substitute of using Linux audit features. It's perhaps the right robustness/complexity trade off for my personal machine, but for work they likely already have audit features turned on and you can access the timing from there.

I think you need to put a number on "likely", here. 80% of all workplaces, maybe? Even that seems a little high. There are a surprising number of devs who have never even heard of auditd. It's just not the kind of thing most people come across in their day to day work unless they go digging for it, or come from a security or DevOps background or something.

That's a good reason to have timestamps in the history, which you should.

Something like

  export HISTFILESIZE=
  export HISTSIZE=
  export HISTTIMEFORMAT="[%F %T] "
  shopt -s histappend

really ought to be default in bash.

It's not as clear why you need it in the interactive prompt.

I didn't make it quite as clear as I should: the reason to have it in the prompt is mostly so that you, or someone you're working with, can spot a trend you may not consciously think to look for if the timestamps weren't in front of you.

It sounds silly, but it has saved my butt more than once. Especially if you have bugs that e.g. only show up once per hour on the hour, and are otherwise fine.

For a personal workstation - you should never "really need it".

It's a personal machine and should be treated as disposable. Doing anything less is fairly irresponsible.

So sure - turn on timestamps for your ssh bastion (although it should be in the logs already...), or turn them on for the ci/cd pipeline (not that you should need them there anyways, since it should be dumping tons of timing info already).

But a personal machine? Plain ol' ">" is plenty.

Not that there's anything wrong with a maximal prompt either... I've definitely done the "configure all the powerline settings!" thing. But I also don't mind a simple ">" or "#".

Well, that's why you build it into the prompt. So you don't give yourself the opportunity to forget.

As an alternative, perennial HN recommendation atuin (https://atuin.sh) logs time, duration and exit code (among other data) for every command.

That way you only have to look at it when you need it, and you can also figure out what you were doing last week/month/year if necessary.

After mucking around for an hour trying to get this information into my prompt, I realised atuin already had it.

Reply on news.ycombinator.com