I see that https://github.com/fish-shell/fish-shell/issues/3341 is scheduled for 3.0. This is also marked as the fix for the broken/invalid YAML format that is used for storing the shell history https://github.com/fish-shell/fish-shell/issues/2258

I implore you to NOT use JSON or ProtocolBuffers, neither are appropriate formats for configuring my shell, or storing long sets of textual data. Protocol Buffers is hardly the kind of format I want to parse and read my history in, and JSON is a less than ideal configuration format for many reasons.

https://github.com/vstakhov/libucl UCL (Universal Configuration Language) is a much more appropriate format for configuring programs than JSON, and is has been accepted as standard for use configuring all tools included in the FreeBSD operating system.

I also suggest you consider using a different language to store shell history, since shell history and shell configuration are two very different jobs with different goals and trade offs. I personally would suggest a simple safe format like TOML https://github.com/toml-lang/toml for storing the history.

But If you do want a single format for both configuration and history, I would implore you to pick TOML not JSON or Protocol Buffers.

Supporting this, I don't think protobuf is a good format for storing history files. Backward compatibility is tricky with it - I don't think the history format is going to change all that much, but I think there were changes in history of fish shell like adding time field. If the choice would be on a binary format, I would much, much, much more prefer SQLite for that. Also, B-trees are perfectly fine choice for searching history, as they make prefix searches trivial.

TOML is definitely an interesting choice if a text format is deemed necessary however. Array of tables syntax should be a fine syntax choice for storing history.

I was about to say SQLite, it seems perfect - binary, fast, easy to update cheaply in place, immune to escaping et al problems (if you use prepared statements, not glue SQL with + of course), reliable, available in most languages (even for C and C++ the integration is trivial - it's a single pair of files drop in) and on the CLI, stable, the history data is very row/item oriented and not totally heterogeneous or free form, etc.

I totally drank the SQLite koolaid a long time ago.

History file may be read & updated simultaneously my multiple processes. Is that sufficiently safe from corruption with SQLite? (honest question, no FUD implied. same risks apply to alternatives too.)

Yes, SQLite has robust multiprocess locking and transaction support. https://sqlite.org/faq.html#q5

In addition protobuf is designed for communications, not incremental updates in a local store. As such making things robust to store things on a development machine is non-trivial. SQLite is so much better for that. After Firefox switched to use it for its own history, most problems with history corruption disappeared.

You can ad extra fields to protobufs just fine, they just need to be added to the end of the definition.

Out of the mainstream formats, JSON is among the easiest to parse - thanks to the CLI tool jq. Does UCL have something equivalent?

Protobuf (or any other binary format) has the benefit of being faster to load, but I agree - it should not be be used to store things like history. It should be easy to parse history without having to write code. And with Protobuf, you need the schema.

If a binary format is going to be used, it should be optional - or perhaps there should be tools to convert the history file to/from a plaintext format.

There is uclcmd [https://github.com/allanjude/uclcmd] which could do with some more work but was created with the intent of being a UCL equivalent of JQ.

Also since he’s the kind of person that a HN reader will probably Ike to know more about. The original author of the aforementioned uclcmd, Allan Jude [http://twitter.com/allanjude], is the former host of the TechSNAP podcast [http://www.jupiterbroadcasting.com/show/techsnap/], current host of the BSD Now podcast [http://www.jupiterbroadcasting.com/show/bsdnow/], a current member of the FreeBSD Core team, and co-authored not one but two books on the ZFS file system FreeBSD Mastery: ZFS [https://www.amazon.com/FreeBSD-Mastery-ZFS-7/dp/0692452354/] and FreeBSD Mastery: Advanced ZFS [https://www.amazon.com/FreeBSD-Mastery-Advanced-ZFS/dp/06926...]

Would like to see comments in configuration, Json doesn't support comments.

UCL can be trivially transformed to JSON or YAML; ucl-tool supports this from CLI.

Thanks for writing that up, I linked to it from the issue. FWIW I agree with you that shell history should be a simple format, and even ad-hoc parseable via Unix tools. zsh uses simple : and ; delimiters. JSON is more complex, and binary formats like protobuf are way out.

Long-time fish user here, I'll second this comment and implore that you choose TOML for the configuration format. TOML format is easy for users to understand, and well-written parsers for it exist in every programming language.

For configuration I would very much prefer to have something that can be properly grepped/patched/generated with shell scripts if necessary. What openssh uses for its config mostly fulfill this, but ini file also are not that bad. Anything hierarchical like JSON/TOML/UCL etc. becomes very unattractive the moment one has to patch them from automated setup scripts.

There pretty mighty tools around to grep/patch/generate JSON data with shell scripts and they are made to deal with hierarchical data.

https://stedolan.github.io/jq/manual/

http://jsonnet.org/

Both are single binaries, so easy to run them where you need it. I don't know comparable stuff for the other mentioned formats, whenever I need to deal with yaml in scripts i run

https://github.com/bronze1man/yaml2json

I would be totally fine with any format that can be converted to JSON on the fly. Of course I would love to have something like these tools more integrated within a shell, but the representing text format on the disk is not that important for me.

Templates in configuration management can help with this a bit.

Thanks for bringing up UCL! Hadn't seen that before but I definitely need to try this in a few places.

Fish shell's design doc [0] was a huge inspiration in the design of pgcli [1] and mycli [2].

Thank you for leading the charge on modern command line design.

[0] https://fishshell.com/docs/current/design.html

[1] https://www.pgcli.com

[2] https://www.mycli.net

Credit where credit is due, nearly all of the design doc was written by Axel Liljencrantz, the author of fish 1.x.

Does this mean... the link between the name and your nick is a coincidence?

Thanks for both your work on fish and for your blog!

I am learning Postgresl for the fun of it and I hadn’t heard of pgcli before. Thanks for mentioning it.

pgcli was a huge help to some former colleagues who had some trouble working with relational databases and SQL for the first time. I'm a big fan myself as well. Thank you for building a great piece of software.

Copy and pasted from another reply: "I still wish fish support && and ||, if only for the times when I copy and paste some one-liner off of stack overflow and have to rewrite it."

That and support for

    SOME_ENV_VAR=foo ./bar

(not having to prepend "env ") are what's stopping me from recommending fish to others.

Btw: Big thank you for fish, it's awesome!

I really like that you have to use `env` in fish, since it's cross-shell - it works in bash/zsh/dash/whatever. The `A=b foo` syntax is an unnecessary appendix in the syntax that complicates matters while only saving 4 characters.

It's not just to save typing - having an `A=b foo` form built-in instead of relying on an external program means `foo` can be an alias or shell function.

I agree and think the best fix would be if the syntax would be forbidden in bash/zsh. Problem is: Millions of code snippets on the Internet not using env.

For one-liners, typing `env ` before pasting is likely not too much work. For longer scripts, you'd have to rewrite much of the text anyway.

often there's stuff like

    cd build && LD_LIBRARY_PATH=../lib ./foo

:/

It's no dealbreaker though, I still use fish and love it :) Just a minor annoyance ;)

That syntax is from very early days of sh itself (predecessor of bash), IIRC. So removing it would break many scripts, as sibling comment by jhasse said.

Agree with these, and would like to add one more:

  $(subcommand)

as an alternative to

  (subcommand)

PS: I have been using fish as my primary shell for about a year now, very happy with it. :)

Good news: Another dev mentioned that they are already discussing this: https://news.ycombinator.com/item?id=15913358

Yes please, even if we have to opt in to this behavior with a patronizing env var :)

While I like fish, I stopped using it because of a small convenience feature ZSH has.

With ZSH, I can run a command with a space at the start so it's excluded from history, even though its not saved to disk, the last command is still stored in memory so I can press Up to access it again.

This is handy when a mistake is made in the command means I need to run it again with some small change.

A large number of electrons have been expended on this topic - see https://github.com/fish-shell/fish-shell/issues/4327 for a starting point. It doesn't seem there's a perfect answer here.

Heh I have the opposite preference, I use space to ensure when pressing up it will not bring up that command, to not mistakingly run it when muscle memory will expect another command there (for mv and rm commands mostly)

This feature seems to exist also in bash. I discovered it accidentally while wondering why my history did not include my last commands (copy/pasted with a leading space).

AFAIK it's not stored in history but also you can't go "up" and run it again which is what parent wants.

Right, only the last command is kept in memory. Run another command and it's lost (which is good IMHO)

I tried fish and it seemed ok, I didn’t continue with it cause I needed to rewrite all my aliases and functions (work related not at home). From memory one was && vs “and” which we use a lot to chain commands. Something like implementing &&/|| would go a long way, compat command sub, closing if statements . I know it seems like a small thing to modify your aliases/functions but I would basically need to modify mine and be a maintainer for the shared ones. TLDR adddition transitionally compat with bash or zsh

If there is anything I would personally like to see it’s the bass plugin rolled into the shell itself to make transitions for bash and some esoteric edge cases easier to handle https://github.com/edc/bass

Maybe adopt a package manager for plugins too? ;)

Regarding the package manager, you should check out https://github.com/fisherman/fisherman

I would love to see zsh navigation tools[0] be integrated in fish. There is a long standing issue in fish which is the support for CTRL-R history, while many are pondering on the UI of it. I would like to see znt's UI be adopted (not saying it's perfect, but quite a good starting point for user conversion).

[0] https://github.com/psprint/zsh-navigation-tools

I have switched to fzf for Ctrl-R history which does seem kind of similar.

Avid fish user since last 3 years. On feature I miss from bash is the `sudo !` to re-run previous command as sudo. Last time I checked fish didn't offer an equivalent. Either that or something similar will be useful

This is easily achieved using a fish function: https://github.com/nyarly/fish-bang-bang

Unlike bash, fish even expands it in place, allowing you to make changes.

zsh also expands in place for double bang, as well as the ^match^replace thing, too. Probably others, but those are the only ones I use regularly.

I missed it too, so I created a fish function:

``` function sudo if test "$argv" = !! eval command sudo $history[1] else command sudo $argv end end ```

This works for `sudo !!`

https://github.com/srynot4sale/dotfiles/blob/master/fish/fun...

Up, Home, "sudo "

Only one more key press than "sudo !" :)

I use up, ctrl-a, then type "sudo ".

!! and !$ are the two miss most.

but similarly, fish user for the last 2+ years.

With !$ you can use Alt+. to write the arguments from the last command.

Alt+. is a bash (libreadline really) key.

In fish Alt+Up does something similar, but repeated presses iterates over all words of all commands rather than last words of bash commands. A big improvement is you can type some chars first and then Alt+Up only gets words matching this substring — like Up but word granularity! (Closest bash key is Ctrl+Alt+I)

If you don't mind the differences, and want Alt+. muscle memory to work in fish too, do:

    bind \e. history-token-search-backward

(plus Alt+Up doesn't work for me in linux console, Alt+. does)

Hey, thank you for contributing to one of my favorite pieces of software :) The Fish shell is my primary choice, because it's so intuitive and easy to use. I never encountered a situation where the Fish shell behaved contrary to my expectations. I do wish there was a native Windows version, because that's where I spend 50% of my digital time, but only because it's so great.

Two things I personally eager to see:

1. equivalent of `set +x` and `set +e` from bash (to echo commands and stop script execution on the first non-zero return) – https://github.com/fish-shell/fish-shell/issues/3427,

2. Associative arrays – https://github.com/fish-shell/fish-shell/issues/390

&& is a major one. Also !! for sudo !!

Fish's FAQ already explains why it doesn't use `!!` – it says that editing commands from history by pressing the up arrow is more memorable and flexible. I don't find it a problem to type “up Ctrl-A sudo” instead of “sudo !!”.

It would be great if Fish supported &&. I know it has its own syntax for this but it's not particularly fun going through a command you copy pasted from elsewhere and swapping out all the &&s (I usually just end up firing up bash).

Care to explain what this does? Thanks

!! is the last command, so sudo !! will run the last command as root.

e.g. apt install foo # you need root permissions to install, won't work sudo !! # will expand to sudo apt install foo, and it'll work!

Thanks for it! I am also using Fish happily for interactive terminal work. Not so much for scripting as I am lazy to learn the new syntax.

What I don't like is that after hitting Tab twice when doing path completion, the list of possibilities comes out, allowing arrow keys to be used for selection. The problem is that it requires pressing Enter to confirm the suggestion and I fear of executing the command with incomplete path prematurely (it's just one more Enter hit away).

What sort of syntactic changes?

Hi, another fish dev here!

We're open to a lot of things (except "make it fully POSIX-compatible"). We're still trying to not massively break everything, though.

The sort of things we've discussed include:

- Not expanding `{}` so you don't need to quote it with e.g. `find -exec {}` (currently this is read as a zero-element brace expansion, i.e. it expands to no argument)

- Removing the `?` single-character glob because it's apparently entirely unused and is another special character to remember (in fact we've also talked about removing `^` as a shorthand for redirecting stderr and `%something` process expansion)

- Allowing `$(command)` command substitutions, which could be used inside quotes as well (long term, these would replace our current `(command)` style)

- Possibly removing the special handling we have for $PATH, $CDPATH and $MANPATH (these are treated by fish as lists, which is nice in some ways and causes pain in others)

For a general overview, see [the fish 3.0 milestone on github](https://github.com/fish-shell/fish-shell/milestone/18).

No thanks, am happy with the shell as is.

I'm very glad to see that getting rid of the magic path variable semantics is a possibility for 3.0 :)

Other than that, my biggest pain point with fish now is that it doesn't interact well with pkg-config (issue #982) and the workarounds for that are a bit awkward. eval is scary and may require double-quoting the non-pkg-config parameters, and string splitting can wrongly split inside quoted text.

Is there any planned work on the vi-mode command line edition ? This is the sole missing feature which make me miss bash from time to time.

Vi mode has been implemented since 2.2.0 (July 2015), although it's an ongoing work in progress - if there's something missing then we'd consider adding it (although nobody's going to reimplement Vim in fish - sometimes Alt-E is your best option).

Sure, but the current implementation has several bugs and could be refined, some motion command does not move where is expected (ie e b e b combos)

the main feature i use fish for is the syntax expansion, and history usage of it. The biggest gripe i have with it is the specific syntax. If fish would act more like a bash shell in case of syntax. ( i know i would need a totally different shell). But it could replace the fish for me in an instant. everywhere. Anyways. Thanks for the fish.

What are some things to look forward to for Fish 3.0?