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.
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions