The document itself is paywalled like all the POSIX specifications, so here are some highlights courtesy of some comments at HackerNews, especially from a-french-anon.

• readlink and realpath
• find -print0, xargs -0 and read -d
• find -iname
• sed -E
• set -o pipefail
• $' ' strings

This release of fish includes a number of improvements over fish 3.6.4, detailed below. Although work continues on the porting of fish internals to the Rust programming language, that work is not included in this release. fish 3.7.0 and any future releases in the 3.7 series remain C++ programs.

Notable improvements and fixes

• Improvements to the history pager, including:
• The history pager will now also attempt subsequence matches (#9476), so you can find a command line like git log 3.6.1..Integration_3.7.0 by searching for gitInt.
• Opening the history pager will now fill the search field with a search string if you’re already in a search (#10005). This makes it nicer to search something with ↑ and then later decide to switch to the full pager.
• Closing the history pager with enter will now copy the search text to the commandline if there was no match, so you can continue editing the command you tried to find right away (#9934).
• Performance improvements for command completions and globbing, where supported by the operating system, especially on slow filesystems such as NFS (#9891, #9931, #10032, #10052).
• fish can now be configured to wait a specified amount of time for a multi-key sequence to be completed, instead of waiting indefinitely. For example, this makes binding kj to switching modes in vi mode possible.
• The timeout can be set via the new fish_sequence_key_delay_ms variable (#7401), and may be set by default in future versions.

Check out the newest version of everyone's favorite^[citation needed] command line json processing tool!

Highlights include significant speed improvements (>10x on some of my workloads), new flags, new builtins, and a litany of bugfixes.

x-post from ![email protected]: https://programming.dev/post/2165136

I'm sure some of you have absolute monstrosities of sigils (I know I do, in my .zshrc alone). Post them without context, and try and guess what other users's lines are. If you want to provide context or guess, use the markdown editor to spoiler-tag your guesses and explanations!

This came out of playing around with curl and the Lemmy API. I wanted a repeatable way to declare a bunch of shell parameters from a json object, so I wrote a jq module! Take a look at the README for examples, or once you install, run

source <( curl 'https://programming.dev/api/v3/community?id=267' | jq -r 'import "shell" as shell; .community_view | shell::param' )

Currently this project only provides a param function, and only supports Bash and Zsh. If I think of other useful helper functions, I may add them to the project.

This uses _ as a default prefix for each parameter. This is so things like {"PATH": "..."} generate typeset _PATH='...' and don't mangle your $PATH, for example. The prefix can be customized by passing in a string: param("mypfx").

Before declaring a 1.0, I'm planning on expanding shell support, and have the function determine how to output using the the $SHELL parameter:

# This does not work (yet!)
eval (curl $URL | jq -r '
  import "shell" as shell;
  "fish" as $SHELL |
  .community_view | param
')

Always up for feedback!

YSH, or the shell formally known as oil, is touted as a possible upgrade path from Bash.

This is the first in a three-part series of posts re-introducing the language.

1. Reviewing YSH
2. Sketches of YSH Features (you are here)
3. YSH, Narrow Waists, and Perlis-Thompson Problems (Not yet released)

YSH, or the shell formally known as oil, is touted as a possible upgrade path from Bash.

This is the first in a three-part series of posts re-introducing the language.

1. Reviewing YSH (you are here)
2. Sketches of YSH Features
3. YSH, Narrow Waists, and Perlis-Thompson Problems (Not yet released)

A huge part of programming in general is learning how to troubleshoot something, not just having someone else fix it for you. One of the basic ways to do that is by tracing. Not only can this help you figure out what your script is doing and how it's doing it, but in the event that you need help from another person, posting the output can be beneficial to the person attempting to help.

(If your shell isn't listed and you know how to enable tracing, comment below and I'll add it to the table!)

Also, writing scripts in an IDE that supports your language. syntax highlighting can immediately tell you that you're doing something wrong.

If an IDE isn't an option and you're using Bash or Sh, you can paste your script into https://www.shellcheck.net/

(Inspired by this post on /r/bash)

Feedback is still welcome, either here or as Merge Requests to my Gitlab Pages repo.