Mac CLI – OS X command line tools for developers

https://github.com/guarinogabriel/mac-cli/

by compassios • 10 years ago

122 73 10 years ago

Etheryte• 10 years ago

As a seasoned dev on OS X I'm not sure if I see the benefits here. You get the same set of instructions but lose (or rather, don't gain, as a beginner) the chance to use google-fu.

compassios17• 10 years ago

Thanks for your comment. I will be updating the code to add modularity in addition of improvements to make it easier to use and extend.

andruby• 10 years ago

That would be great! I would love to have some mac specific commands, but I don't care for the lamp/magento/git commands.

Is there a way to install only the dependencies that one cares about?

mmfZ4e4OqQ7RRwP• 10 years ago

Not only that, by abstracting cross platform commands for things like git you give up the knowledge which allows you to go to other platforms and work there. Unless this mac thing would be ported to linux, windows, etc.

eridius• 10 years ago

Looks like a nice collection of tools, but unfortunately the installation process assumes you want to install Homebrew (as if you haven't already), install pip, and install git, pv, and python through Homebrew. I don't want to perform those steps. I already have Homebrew, pip, and git installed, and I have pv and python installed using Nix.

compassios17• 10 years ago

That's true. One of the pending tasks on the script is modularity in addition of a customizable installation process. Stay tuned!

pskocik2• 10 years ago

I'm quite unfond of this command suite pattern that seems to be popular in cli apps lately. It's a very git thing to do. Why not just mac-whatever1 mac-whatever2? It has less coupling, basic autocompletion out of the box, and generic autocompletion very easily generatable in a context-free fashion, but less coupling alone should be enough of a reason.

compassios17• 10 years ago

I agree 100% with you. I am working on a modular version of the script and I will update the code soon. Thanks for your comment!

pskocik2• 10 years ago

I appreciate your appreciating my jibe. Good luck with your suite and sorry for the little bit of negativity. Command line apps are my favorite type of apps.

shykes7• 10 years ago

I would advise finding another name for the tool. 'mac' is an obvious trademark infringement and it's only a matter of time before Apple lawyers come knocking on your door. Honestly I find it uncool to piggyback on someone else's brand in this way. The protagonists are different but it's the same fundamental issue as the "Ubuntu vs OVH" and "Let's Encrypt vs Comodo" stories we've seen recently.

compassios17• 10 years ago

Thanks for your advice! Do you have any suggestion regarding the name? I'd love to hear some ideas.

shykes7• 10 years ago

I don't have any suggestions, but will be happy to send them if I think of anything.

The sooner you change, the better. Otherwise that is wasted brand equity for you. If you're going to work hard to build a great tool, the recognition for that should flow to a name of your own.

nestlequ1k2• 10 years ago

As an open source library, don't worry about it. If Apple causes a big stink about it (unlikely), then you can rename it.

What you have is a great, simple, direct name for a utility script. Better to ignore the trademark / brand FUD.

godzillabrennus• 10 years ago

If in doubt click on this sites generate button a bunch and see if anything manifests that you like.

https://www.dotomator.com/web20.html

nicerobot• 10 years ago

Call it `morc`.

tacone• 10 years ago

Call it PC, and nobody will complain.

syngrog66• 10 years ago

Mackly -- sounds like "Mac CLI", and has personality. tho have not googled for collisions

retreatguru• 10 years ago

What about max?

Razengan2• 10 years ago

You way want to change all occurrences of "OS X" to "macOS" :)

vonklaus2• 10 years ago

i think the difference is that this is an open source command line utility for mac, so the naming convention is essentially mac command line utility. I think you are correct that it could cause issues, but nowhere near the same thing as Commodo wherein they intentionally are trying to undermine a competitors offering by intimidation and coercion.

Not sure what a better name would be, but it may need to be changed. I should add though, I had no illusions this wasn't an official apple offering.

compassios17• 10 years ago

If you have any suggestion regarding the name, just let me know! I am open to receive suggestions about that. Thanks!

shykes7• 10 years ago

I agree the circumstances are very different, and obviously don't think there was any nefarious intentions. But the underlying fundamental issue - brand recognition and the value of having your work recognized under a name you control - is still the same.

In this case, I think the author of this tool has the most to lose, because he is building brand equity for someone else. If next year his tool takes off and he is forced to rename, he has to start over.

But let's assume this tool becomes so successful that he gets away with the "name hack", then it sets the wrong example for other aspiring toolmakers: "don't bother picking your own name, surf on on someone else's and if you succeed fast enough, you might get away with it". That is the same calculation which leads less scrupulous people like Comodo and OVH to "ask for forgiveness rather than permission". I think that is dangerous for innovation because it makes it less rewarding to try something new under your own name. Why bother if someone else will reap the rewards in the end?

Razengan2• 10 years ago

There is other non-Apple software that has been happily using "mac" in its name for a long time, no?

Everybody knows MacPorts, and there's Mactracker and MacCleanse on the App Store itself, and the infamous Mackeeper (which may very well be malware; Apple should go after them first) and companies: MacPhun and MacPaw.

But I guess people may confuse "Mac CLI" as being an official part of macOS.

Waterluvian• 10 years ago

Without reading the article I assumed this would be some tutorial on official Mac OS tools. Once I read it, it was obviously not the case.

Just anecdotal evidence.

Alphasite_• 10 years ago

Apple provides support and funding to Mac ports when I last checked.

JustSomeNobody4• 10 years ago

What's so wrong with the regular command line commands for most of this?

nestlequ1k2• 10 years ago

Most people don't memorize the commands for all of these, and googling for them everytime gets old.

compassios17• 10 years ago

Exactly. In addition to that, this is a chance to collaborate to build more and better commands. It's the first step to what could be a powerful and very useful developer tool.

JustSomeNobody4• 10 years ago

man <command>.

And if people are in the command line often enough, they do memorize the actual commands. They really, really do.

ksherlock• 10 years ago

So instead of not remembering "tar xfz", you can not remember "mac tar:extract"? Either way, I guess you'll just end up asking google and google will tell you to use tar.

pje• 10 years ago

Well, would you rather remember: `sudo shutdown -r now` or `mac shutdown`?

Would you rather remember: `pmset sleepnow` or `mac restart`?

compassios17• 10 years ago

Exactly, that is the point. Also, some commands require several parameters and it's much better having the script asking for those parameters in an interactive way.

For example: mac ssh:download-folder

dottedmag• 10 years ago

Is there complementary `linux shutdown` and `freebsd shutdown` and `solaris shutdown`? If no, then this utility only increases cognitive load.

spike021• 10 years ago

Why not just do `man shutdown` to figure out the option you should use, and then either set it up with an alias or just learn it permanently with repetition?

JustSomeNobody4• 10 years ago

sudo shutdown -r now.

1) It's already muscle memory.

2) It's not hard.

3) Other *nix OSs use is too.

Obi_Juan_Kenobi• 10 years ago

FWIW, I was installing Ubuntu and had an issue with Unity, so had to use tty to update and hadn't ever shut down from the command line before. It just took me one try of 'shutdown' and a quick look at the man page to figure out what options were needed.

I see this as either being used frequently enough to be easily memorized, or infrequently enough that a quick check of the man page is fine. The real benefit is that it's a very general solution that works on basically any system, and for a wide variety of commands. As another commentor pointed out, the apropos command makes this strategy even more powerful.

sepbot• 10 years ago

I agree. It did inspire me to write this however, which I desperately needed for a long time:

alias eject="hdiutil info | gawk '/^\/dev\/disk([0-9]*)\>/ { system(\"hdiutil detach \" \$1) }'"

gradstudent• 10 years ago

This project rather reminds me of Joel Spolsky's Law of Leaky Abstractions:

http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

vbezhenar• 10 years ago

I would suggest another command. Instead of "XXX:extract" I use my little shell script, which runs correct unarchiver basing on the file name (or series of unarchivers for common cases like .tar.gz). So you don't have to memorise every command out there. Another useful functionality is to create a separate directory, if archive contains multiple "root" files, so the current directory won't be polluted by the bad archive.

compassios17• 10 years ago

That is great! Could you create a Github Issue to move forward with that?

rafa2000• 10 years ago

How about 'climate'?

ohthehugemanate• 10 years ago

Ha - I just got it. CLImate, right? I like it. I was gonna suggest something like termtool, or just term.

datihein• 10 years ago

Please, everyone, stop forcing HomeBrew as a dependency.

HomeBrew screws with your systems file permissions and installs directly into the standard system directories.

MacPorts (https://www.macports.org/) is at least a good, and it installs into the /opt tree, staying out of the way of anything Apple or Darwin wants to do when updating or patching your system.

Don't like MacPorts? There's always Fink (http://www.finkproject.org/), which installs into /sw and looks like Debian (i.e. apt-get).

HomeBrew seems like the worst of the three. :-(

glasz• 10 years ago

i've been using homebrew since, like, lion and never had major issues. it also always worked across major and minor mac os upgrades. the things it does in /usr/local don't interfere with mac os.

in contrast, i somehow couldn't manage to efficiently use macports and fink.

jimjag• 10 years ago

I really don't get this... it seems like simply a way to create an environment where you need to prepend 'mac' to every command.

juandazapata• 10 years ago

Why?

Mac CLI – OS X command line tools for developers

Related Stories