Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modules/directory vs modules/utility #851

Closed
leoj3n opened this issue Apr 13, 2015 · 5 comments
Closed

modules/directory vs modules/utility #851

leoj3n opened this issue Apr 13, 2015 · 5 comments

Comments

@leoj3n
Copy link
Contributor

leoj3n commented Apr 13, 2015

I feel there is some organizational inconsistency between the directory module and the utility module because they both include aliases related to directory switching. My opinion is the directory aliases should all be in the directory module or all in the utility module and not split up between two modules. Thoughts on this?

@sorin-ionescu
Copy link
Owner

You might be right. They remained in utility after the project was forked from Oh-My-Zsh. Utility ought to contain stuff that doesn't fit anywhere else.

@ressu
Copy link

ressu commented Apr 16, 2015

Both of the directory and utility modules also need a way to disable some of the safeties. Both of the modules contain useful things but for someone who lives in the terminal shell, all the safeties get in the way.

I was just about to send a pull request adding a safety-off option to the utility module which would have disabled the interactivity in cp, mv & friends. But after thinking about it a bit, I realized that utility should be split into parts as well. The dircolors part should be in a separate module. It's not really an utility, but rather a feature that manipulates ls and friends. Same goes for the other coloring options.

As for the directory module, things like unsetting CLOBBER do not fit in to directory behaviour.

@sorin-ionescu
Copy link
Owner

@ressu, submit your changes, and I'll have a look. If you make constant backups, safety is not useful; if you don't, it very much is. I have been burned many times by overwriting or deleting the wrong file; it ceased when I have turned on safety.

@ressu
Copy link

ressu commented Apr 17, 2015

I'll see if I manage to get back to the changes this weekend. I undid all my changes after I started thinking about the organization a bit.

As for the safety settings, I've found that too much safety makes you careless since you can always rely on the safety net to catch you if you make a mistake. What happens when you don't have the safety net in place?

In any case, my solution was to add a flag that allows the user to disable the interactivity in certain commands, but leave it undocumented. Even if I prefer to not use safeties, I don't want to promote disabling them.

@leoj3n
Copy link
Contributor Author

leoj3n commented Aug 7, 2018

@belak Should revisit this perhaps?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants