Last week I noticed a pattern in some of my shell workloads:\nrun something in a shell, go change some code, run it again.\nAnd often I'm looking for some sort of change between runs.
\nOne of the most common things that could change (which I may not always notice)\nis how long the thing took to run.\nYou could solve this with a utility like time, but you have to remember that,\nand it also pollutes your shell history, obscuring the actual thing you were trying to run.
Another common workflow is comparing somewhat detailed log outputs for differences.\nA single shell scrollback buffer is TERRIBLE for this,\nbecause you can't compare things side-by-side.\nSo I often use multiple tabs/buffers/windows.\nThis introduces a new problem though: remembering which one you ran last!\nIt sounds silly, but I may go heads down for hours and it's very easy to forget!
\nI solved both of these with a better shell configuration.\nI'm using nushell, but something similar should be achievable in most shells:
\n# Right prompt: duration of the last command.\n$env.PROMPT_COMMAND_RIGHT = {||\n let ms = ($env.CMD_DURATION_MS? | default "0" | into int)\n if $ms < 1 {\n ""\n } else {\n $"took (($ms * 1_000_000) | into duration)"\n }\n}\n$env.TRANSIENT_PROMPT_COMMAND_RIGHT = null\n\n# Inserts a timestamp right before executing a command (after you press enter).\n# I tried doing this with a transient prompt, but one interesting (useful?)\n# property of nushell is that many things are required to be known and static at some point in time.\n# This property applies to prompts.\n# The prompt is evaluated only once, so the timestamp is the moment at which the prompt was rendered,\n# which may be long before you execute the next command.\n# So barring weird terminal tricks to edit previous lines, this is the best solution I've come up with so far.\n$env.config = (\n $env.config\n | upsert hooks.pre_execution [ {||\n # $env.repl_commandline = (commandline)\n # print $"Command: ($env.repl_commandline)"\n let stamp = (date now | format date "%Y-%m-%dT%H:%M:%S%:z")\n print $"@($stamp)"\n } ]\n)\nOnce you've made the edits, you can reload your config with exec nu.\nAnd now your scrollback is a log!\nEvery entry has a start timestamp and a duration.
I've been using nushell as my daily driver for about six months now,\nand wanted to show a few simple examples of why I'm enjoying it so much.\nI think it's a breath of fresh air compared to most shells.
\nIn case you've never heard of it before, nushell is a, well, new shell ;)\nbash has been the dominant shell for as long as I can remember,\nthough zsh have their fair share of devotees.\nfish is the only recent example I can think of as a "challenger" shell.\nfish gained enough traction that it's supported by tooling such as Python virtualenv\n(which only has integrations out of the box for a handful of shells).\nI think fish is popular because it had some slightly saner defaults out of the box,\nwas easier to "customize" with flashy prompts (which can make your shell SUPER slow to init),\nand had a saner scripting language than bash.\nBut it still retained a lot of the historical baggage from POSIX shells.
Nushell challenges two common assumptions about shells\nand asks "what if things were different?"
\nls and du) are replaced by builtins.By dropping the goal of POSIX compliance,\nnushell frees itself from decades of baggage.\nThis means you get a scripting language that feels a lot more like Rust.\nYou'll actually get errors by default when you try to do something stupid,\nunlike most shells which will happily proceed,\nusually doing something even more stupid.\nMaybe treating undefined variables as empty string make sense in the 1970s,\nbut that's almost never helpful.
\nnushell also takes a relatively unique approach to utilities.\nWhen you type something like ls or ps in nushell,\nthis is handled by a shell builtin!\nIt's just Rust code baked into the shell rather than calling out to GNU coreutils\nor whatever your base system includes.\nThis means that whether you type ps on FreeBSD, Debian, or macOS,\nyou'll get the same behavior!
I can already hear some readers thinking "doesn't this just massively bloat the shell?"\nNo, not really.\nThe code for these is for less than that of the typical GNU utility,\nbecause nushell actually (IMO) embraces UNIX philosophy even better than the original utilities.\nThey are all extremely minimal and work with other builtins.\nFor example, there are no sorting flags for ls,\nand no format/unit flags for du.
The reason that nushell can take this approach is because they challenge the notion that\n"text is the universal API."\nYou can't meaningfully manipulate text without lots of lossy heuristics.\nBut you can do this for structured data!\nI admit I'm a bit of a chaos monkey, so I love to see a project taking a rare new approach\nin space where nothing has fundamentally changed since the 1970s.
\nOkay, enough about philosophy... here are a few examples of some shell pipelines I found delightful.
\nFirst up: I do a lot of work with Elasticsearch during $DAYJOB.\nOne workflow I have to do fairly often is spin up a cluster and restore from a snapshot.\nThe Elasticsearch API is great... for programs.\nBut I have a hard time grokking hundreds of lines of JSON.\nHere's an example of a pipeline I built which culls the JSON response down to just the section I care about.
http get "http://localhost:9200/myindex/_recovery"\n | get restored-indexname\n | get shards\n | get index\n | get size\nIn case it's not obvious, the http command makes HTTP requests.\nThis is another nushell builtin that is an excellent alternative to curl.\nIt's not as feature-rich (curl has a few decades of head start),\nbut it brings something new to the table: it understands from the response that the content is JSON,\nand converts it into structured data!\nEverything in this pipeline is nushell builtins.\nAnd it'll work on any OS that nushell supports.\nEven Windows!\nThat's wild!
Pro tip: you can press option+enter to add a new line when typing in the shell.
\nHere's an example I hinted at earlier.\nIf you type help du (to get built-in docs),\nyou won't find any flags for changing the units.\nBut you can do it using formatters like so:
du path/to/bigfile.bin | format filesize B apparent\nThe du command always shows human-readable units by default. Which I very much appreciate!\nAnd did you notice apparent at the end there?\nWell, the version of du you'd find with a typical Linux distro doesn't exactly lie to you,\nbut it withholds some very important information.\nThe physical size occupied on disk is not necessarily the same as how large the file\n(in an abstract platonic sense) actually is.
There are a bunch of reasons for this, but the most impactful one is compressed filesystems.\nIf I ask Linux du how large a file is in an OpenZFS dataset,\nit will report the physical size by default, which may be a few hundred megabytes\nwhen the file is really multiple gigabytes.\nNot necessarily helpful.
Anyways, the nushell builtin always gives you columns for both physical and apparent.\nSo you can't ignore the fact that these sizes are often different.\nI like that!
\nIf you want to give nushell a try,\nthey have some great documentation.\nRead the basics, but also check out their specific pages on, e.g.\ncoming from bash.
\nFinally, here are two more that tripped me up at first.
\n$nu.pid instead of $$.$env. On the plus side, you can now explicitly differentiate from environment variables.