Hacker News new | ask | show | jobs
by sliverstorm 4778 days ago
I just wish it didn't insist on doing everything differently. For example, PATH is traditionally delimited with colons in just about every shell; fish uses spaces. This instantly breaks compatibility with legacy environment configuration, and for no particularly good reason that I can see.

I was excited to try fish, but I found it impossible to get configured in an established environment with entrenched bash usage (which zsh, by the way, has no problem with)

3 comments

Do you mind sharing more details about your legacy environment configuration? How are you currently setting $PATH? Usually the differences in syntax for setting variables causes more problems than the colons.

Regarding $PATH: it is actually not delimited at all in fish. Instead, $PATH is an array, which is a first class notion in fish. This allows for nice tricks like, say, looping through $PATH:

   for dir in $PATH
        echo $dir
   end
or deleting its last entry:

    set --erase PATH[-1]
Of course, fish flattens $PATH into a colon-delimited string when setting it as an environment variable, and unflattens it when reading it from the environment.
PATH gets set the way it always did. For example in bash:

export PATH=$PATH:<new_dir>

As for the larger question of environment configuration; we pull in a number of shell configuration scripts owned by the infrastructure teams. You are right, there is no universal way to set path due to things like "export" vs "setenv", but often multiple shells support the same syntax so you can sometimes use a config script meant for bash in zsh, for example. I had hoped that fish would be able to use csh scripts, because it shares "setenv", but csh of course delimits PATH with colons.

You say that PATH is treated as a colon-delimited string when accessed as an environment variable... Hmm. That wasn't what I was seeing, but it is entirely possible I made a mess of things, or that I broke things when I compiled it.

Anyway, it's unlikely I personally will be able to use fish. I hit many more obstacles than just PATH, but that was the easiest example and I thought I'd share some feedback.

Thanks for elaborating. Yes, it's a common issue to encounter configuration scripts, .profile files, etc. that use POSIX syntax, and it's understandable that people will be unwilling or unable to port them to fish. Usually these are just standalone scripts which can be run directly via /bin/sh, but sometimes you want them to be part of your interactive shell.

https://github.com/fish-shell/fish-shell/issues/522 tracks having a bash compatibility layer - as you can see there's a lot of discussion!

I've solved the configs-in-other-shells problem by writing a translator that sources the target config file, and then exports the needed variables in their desired syntax for my shell of choice. Simple example (config in csh, my language of choice was bash):

   jsoc_mach=`csh -f -c 'source /home/jsoc/.setJSOCenv && echo $JSOC_MACHINE'`
It could be abstracted farther.

Still a pain point, though.

So you add one line to your config to replace colons with spaces? I'm not sure that's a legitimate reason to bail on trying it.
I don't own all the configs.
fair.