[jonfw]

The parsing and setting of environment variables was always my #1 hassle with fish. I feel like I see a lot of BASH snippets that get copy pasted around that I always had to re-write or throw in a sub shell. Particularly annoying when you're trying to do something while screen sharing and somebody gives you a snippet which you have to re-write before using it- "Oh yeah it's a hassle but I've got sweet auto-complete" gets old

[mhink]

IMO, copy-and-pasting bash commands is an organizational smell to begin with, but I don't think this particular use case is a reason not to use one shell over another. If you do have a snippet of bash to run, it's easy enough to toss it in a file (with a shebang) and run it as a shell script. And as a bonus, it's reusable and you can add comments/notes for when you have to run it again.

[jonfw]

> IMO, copy-and-pasting bash commands is an organizational smell to begin with

The people who develop the automation have to start somewhere :). If you're standing up a test environment or a PoC, writing down commands get's you 80% of the way to reproducing your results

[omginternets]

I think the bigger issue is with programs (e.g. nvm) that are either implemented as collections of shell scripts, or function by dynamically generating shell commands.

[bostonvaulter2]

Fish now supports setting environment variables for a command easier. Previously you had to do

    env MIX_ENV=prod mix compile

Now you can just do

    MIX_ENV=prod mix compile

But I also generally don't use fish for any scripting, I just use bash for that. But at least some copy-paste commands aren't as difficult to translate now.

[omginternets]

Agreed. I really wish they would adopt `export`. It's not like `set` is any better.

[duckerude]

It has had `export` for years: https://github.com/fish-shell/fish-shell/blob/master/share/f...

[omginternets]

Mind blown.

This is the best news I've heard all week. Thank you kind stranger!