Skip to content

Split nix-shell logic #777

@copumpkin

Description

@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

Metadata

Metadata

Assignees

Labels

UXThe way in which users interact with Nix. Higher level than UI.cliThe old and/or new command line interfacesignificantNovel ideas, large API changes, notable refactorings, issues with RFC potential, etc.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions