-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
utility: add support for g-prefixed coreutils ls #1786
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am okay with this change. I realize it changes default behavior, but I doubt it will affect that many folks. I also suspect those affected will primarily be advanced users with the knowledge to figure it out pretty quickly. And the new behavior after this change seems better to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to say the same thing that @jeffwidman was going to say, so this is good to me.
I myself have not installed gnu coreutils yet, because I wasn't aware of this being available on my mac. So you've lifted me to the idea here, thanks! 👍 But seeing this brings me to the idea to look if it'd make sense to do something similar with darwin users having gnu- programmes installed. I for example, have |
This actually already exists in https://github.com/sorin-ionescu/prezto/tree/master/modules/gnu-utility. On a similar note, maybe it would make more sense to only change to the g-prefixed tools if gnu-utility is enabled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly, good idea. But there might be a way to minimize user surprise but accommodating the corner cases on a "best effort" basis. What say?
if is-callable 'gdircolors'; then | ||
-define-coreutils-aliases g | ||
alias ls="${aliases[gls]:-gls}" | ||
|
||
elif is-callable 'dircolors'; then | ||
-define-coreutils-aliases |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we consider honoring user configured ':prezto:module:gnu-utility'
zstyle instead of assuming g
?
Granted Homebrew doesn't honor customizing g
prefix for gnu coreutils anymore, but macport still does.
Besides, if a user loads gnu-utility
module, both ls
and gls
would be candidate for alias modification. Shouldn't we support both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, it might be tricky with some of the g_
prefixed GNU utility commands/aliases -- particularly the ones used with git
module (gls
is aliased to git log
for example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catches. I'm not 100% sure what the proper fix is on this... coreutils are a bit of a pain to detect and work with especially with the git aliases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Took another (rather opinionated) attempt at addressing this here #1917. Criticism/comment appreciated :)
Fixes #1758
Proposed Changes
Note that this does change default behavior a bit by changing which ls will be selected for the default alias.