Split nix-shell logic

[copumpkin]

I just ran into the usual issues with zsh support (e.g., #498 and #545)

In the longer run, it seems like the current implementation of nix-shell -p might not be sustainable (since it's basically pretending to run a dummy build, using constructs that assume bash), and perhaps should move to something more like a temporary nix-env behavior. Perhaps we should rename the current nix-shell to nix-build-shell for running and debugging nix builds (which legitimately assume bash), and nix-shell be something a bit more user-focused which supports custom shells and explicitly doesn't need its environment to be filled with assorted bash-centric build functions?

This also relates to #726

[Ericson2314]

Big +1

[cstrahan]

Is the idea to not run the stdenv's setup stuff in nix-shell? IIUC, that's what's responsible for setting up stuff like $PKG_CONFIG_PATH, and I'd hate to see duplication for that kind of logic. It might be more worthwhile to just avoid too many bashisms (granted, that might not be amenable to shells that deviate greatly from bash like syntax).

[nioncode]

Any progress on this? I almost exclusively use nix-shell for developing (C/C++) like virtualenv and would prefer nix-shell to behave more user friendly.

[stale]

I marked this as stale due to inactivity. → More info

[stale]

I closed this issue due to inactivity. → More info

[Ericson2314]

CC @roberth we are, finally, getting to these issues somewhat.