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

Merge 'deb' and 'debian' plugins #529

Merged
merged 7 commits into from
Oct 10, 2011
Merged

Merge 'deb' and 'debian' plugins #529

merged 7 commits into from
Oct 10, 2011

Conversation

dbb
Copy link

@dbb dbb commented Aug 6, 2011

As far as I can tell, the deb plugins were already covered in the debian plugins. So there's really no need for the two separate plugin directories. However, the deb plugins used sudo (instead of su -c) and had shorter alias names, so I incorporated them into the debian plugins so users will have more options. The reason that I kept the name debian is that it's a little less ambiguous.

-dbb

@ghedo
Copy link
Contributor

ghedo commented Aug 7, 2011

Instead of # aliases that use su -c and # aliases that use sudo, they should say # aliases that use aptitude and # aliases that use apt (which sounds a bit more useful). To do that the as alias should be updated to use apt-cache (see here, I didn't have the time to push this upstream), and maybe create another alias to use the current aptitude command (something like aps?). Could you please do this?

Also, not sure whether sudo is better than su -lc, but I surely prefer the former, and other plugins (yum and macports) do too, what about using it for all the aliases?

/me being the original author of the deb plugin.

@dbb
Copy link
Author

dbb commented Aug 7, 2011

The real problem is that we have aptitude v. apt-get and su v. sudo, which results in a lot of permutations. I didn't mean to imply that one or the other is better.

The reason I don't use sudo is that it was meant to give very specific superuser permissions to specific users, and I am the only user on most of my machines so I really have no use for it-- I trust myself to simply use root to do all administrative work.

As for aptitude v. apt-get, that one is mostly a judgment call (except for apt-get source, for which aptitude has no alternative last I checked).

I think maybe the best solution is to set two preference variables, and then write a function that incorporates those preferences into the aliases whereever possible. This will also avoid confusing namespace issues (e.g. "as" v. "aps"). I think I could finish this in a day or two.

@dbb
Copy link
Author

dbb commented Aug 7, 2011

Another possibility is that I could write a function that uses sudo by default if which sudo exists, and resorts to su if it doesn't. And for the aptitude/apt-get, aptitude aliases could start with at and apt-get with ag (but who wants to type an extra character?)

@ghedo
Copy link
Contributor

ghedo commented Aug 7, 2011

Another possibility is that I could write a function that uses sudo by default if which sudo exists, and resorts to su if it
doesn't

Agreed.

And for the aptitude/apt-get, aptitude aliases could start with at and apt-get with ag (but who wants to type an extra
character?)

Why not use aptitude if which aptitude exists? There could be a variable to use apt if both exists, but it seems a reasonable default to me.

@dbb
Copy link
Author

dbb commented Sep 11, 2011

Are any project admins even reading the pull requests?

@robbyrussell
Copy link
Member

"Are any project admins even reading the pull requests?"

Sometimes... just have a big backlog to work through. Merging in 3...2..

robbyrussell added a commit that referenced this pull request Oct 10, 2011
Merge 'deb' and 'debian' plugins
@robbyrussell robbyrussell merged commit b8ade48 into ohmyzsh:master Oct 10, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants