Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS command-line tools you might not know about

saurabhs.org

Post reply on HN
Print view View original

371–380 of 454 posts

Re: macOS command-line tools you might not know about

#371

Post by krackers »

alexdbird wrote: post #40
maxfurman wrote: post #27

I remember Caffeine used to be a third-party program that would prevent your Mac from sleeping, same behavior as the `caffeinate` here. Were they acquired and incorporated into the OS?

I believe that Caffeine was a fairly simple GUI wrapper for the existing caffeinate command

From what I recall, caffeine app predated the caffeinate command (which was only introduced in lion). Caffeine.app also disables sleep via a completely different method than caffeinate. The latter uses a IOPMAssertion which is the recommended way to do it because it is visible in `pmset -g assertions` whereas the former doesn't use that approach (I forgot how exactly it did it, there's like 4 different methods on osx to prevent sleep).

Re: macOS command-line tools you might not know about

#372

Post by vram22 »

latexr wrote: post #125
paulddraper wrote: post #115

Earlier quoted context omitted.

They avoid an unnecessary invocation of the cat executable. Instead, they open a file descriptor and pass that. Tiny difference but there you go.

To add, searching for “useless use of cat” will yield several results for those interested in learning more. Other examples include “useless use of echo” and “useless use of ls *”.

Yes.

Even the Wikipedia page on cat has a section about that, titled eponymously.

https://en.m.wikipedia.org/wiki/Cat_(Unix)

Re: macOS command-line tools you might not know about

#373

Post by reaperducer »

fredoralive wrote: post #264

I'll go for the somewhat obsolete `drutil eject` as Mac OS can be sometimes rather reluctant to eject cycle optical drives if it doesn't actually think a disc in in them. Although nowadays you'll probably be using a 3rd party tray load drive with an eject button instead of a no-button slot loading Apple one.

My LG Blu-Ray drive ignores its eject button if it's connected to a Mac, unless the drive is empty, so I use this, too.

Re: macOS command-line tools you might not know about

#374

Post by saagarjha »

1f60c wrote: post #346
lastangryman wrote: post #242

I find it extremely upsetting that `networkQuality` is the only command that is not entirely lowercase. How did this get through PR??

APFS isn't case-sensitive, so you can type networkquality if it makes you happy. :-)

It can be, it’s just not by default.

Re: macOS command-line tools you might not know about

#375

Post by manifoldgeo »

sovietswag wrote: post #188

Needs to mention afplay for playing audio! You can easily use this to make a command-line MP3 player. Others have mentioned the “say” utility for speech synthesis. There is a lot you can do with it, it supports the TUNE format, which allows you to "shape the overall melody and timing of an utterance... for example ... to make an utterance sound as if it is spoken with emotion". See: Apple's Speech Synthesis Programmi…

Thanks for posting! I'm always glad when I discover good blogs like yours.

Re: macOS command-line tools you might not know about

#376

Post by timf »

cerved wrote: post #173
timf wrote: post #101

Earlier quoted context omitted.

Since I'm bouncing between OSX and Linux a lot, I have a shell script with the same name on each that boils down to: if [ `uname` == "Darwin" ]; then pbcopy else xsel --clipboard fi

why not just alias?

Could be an alias, I have a limited set of aliases for each type of system. But I keep a repository of hundreds of personal shell scripts and it fit better there.

Re: macOS command-line tools you might not know about

#377

Post by FabHK »

Another one that comes in handy occasionally is afconvert to convert audio files. I like to add audio files (eg audio books, or guided meditations) to iTunes/Music or Books, and they are a little bit finicky in terms of what they accept and sync (I've had problems with files converted with ffmpeg).

I use this to convert an mp3 to a variable rate m4b for Books:

    afconvert -v -s 3 -f m4bf meditation1.mp3

Re: macOS command-line tools you might not know about

#378

Post by m463 »

RoyGBivCap wrote: post #367
m463 wrote: post #290

Earlier quoted context omitted.

I have a script always running that polls for youtube URLs using pbpaste and runs yt-dl then just highlight any youtube link and COPY later when I have time, I can use quicklook to browse directory of youtube videos.

FYI: yt-dlp is more up to date and faster, AFIK: https://github.com/yt-dlp/yt-dlp I download and save it as 'ytdl' for convenience, but I use it all the time on twitter too.

sorry mistyped, that's what I use

Re: macOS command-line tools you might not know about

#379

Post by andrei_says_ »

e28eta wrote: post #243
andrei_says_ wrote: post #204

Earlier quoted context omitted.

For me it’s one of the top benefits of the Apple ecosystem. The only drawback is that yes it only works most of the time. And when it doesn’t I get infuriated. Glitches happen without any change to settings or network on my side - it works now, and 5 min later doesn’t.

Some of the “not working” cases may be due to the application you’re copying from setting the items as `localOnly`, ex: from a password manager. I don’t have an explanation for other failures. https://developer.apple.com/documentation/uikit/uipasteboard...

Yes it’s 1Password. I use the very old, iOS only non subscription version 7.something. But I think sometimes it works (copy from iOS paste on MacOS).

Re: macOS command-line tools you might not know about

#380

Post by chlorion »

adrianmonk wrote: post #148
paulddraper wrote: post #115

Earlier quoted context omitted.

They avoid an unnecessary invocation of the cat executable. Instead, they open a file descriptor and pass that. Tiny difference but there you go.

Not just that, but also all the bytes have to go through an extra pipe. Presumably they're copied an extra time because of this. When you run "cmd < file", the command reads from stdin, which pulls directly from the file. When you do "cat file | cmd", "cat" opens the file, reads from there, and writes to a pipe. Then "cmd" reads from its stdin, which is a pipe.

GNU cat will use the copy_file_range syscall when possible!

copy_file_range allows a user land program to copy data between two files without doing any user space work. Instead of reading data into a buffer and writing it back out to the destination, the kernel will somehow manage to move the data for you.

I think this will prevent any extra copies from occurring in situations where it can be used.

https://man.archlinux.org/man/copy_file_range.2

https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat...

Post reply on HN