I find it so annoying that these only work with plain text and RTF. On X11 there is `xclip`[0] and on Wayland there is `wl-clipboard`[1] both of which support binary file formats either through parsing the header or explicitly setting the MIME type.

This means you can do things like copy an image from the terminal and paste it into a graphical program like a browser or chat client and vice-versa. Also can be very useful in shell scripts for desktop automation.

The workaround on MacOS is to use AppleScript via `osascript` to `set the clipboard to...`.

  [0] https://github.com/astrand/xclip
  [1] https://github.com/bugaevc/wl-clipboard

Since you mention both pbcopy and iTerm - I love https://github.com/skaji/remote-pbcopy-iterm2. I do most of the work on a remove Linux server, treating my MacBook as mostly a dumb terminal, and being able to transparently copy from the remove to my local clipboard is so nice.

I’ll have to try that. More than once I’ve been logged in to a remote host and got “pbcopy not found” “What!?… oh, right.“

The tmux integration in iterm is also very nice for remote work if you haven’t tried it out.

I have tried it, but for whatever reason I just don't like it. I prefer just running tmux in iTerm with no integration.

On the topic, you can also integrate tmux with the native clipboard - I have set copy-pipe to the remote pbcopy, so any selection done in tmux get copied to my local clipboard. I also just found out that tmux also support it natively (https://github.com/tmux/tmux/wiki/Clipboard#the-set-clipboar...).

If I had a nickel for each `cat foo.json | jq | pbcopy`, I'd be a rich man :)

That's a useless use of cat. You can use `jq . foo.json | pbcopy` or `jq < foo.json | pbcopy`.

Speaking for myself, the first form is more natural- even if it’s a useless cat, because I’m always cat-ing files to see their structure. Then progressively tacking on different transforms. And then finally putting it in whatever I want as output.

It’s so ingrained, I’m more likely than not to just write it out that way even when I know exactly what I’m doing from the onset.

Yes, this iterative procedure is often why "useless" cats get put into it. It's a very effective way of processing regular text information.

e.g.

I need to grab some info from textfile.txt to use as arguments to a function.

cat textfile.txt

looks like its comma delimited.

cat textfile.txt | cut -d, -f 2-5

ah, its the third and fourth column i need

cat textfile.txt | cut -d, -f 3-4 | grep '123456'

perfect

cat textfile.txt | cut -d, -f 3-4 | grep 123456 | tr , ' '

myfunc $(cat textfile.txt | cut -d, -f 3-4 | grep 123456 | tr , ' ')

> cat textfile.txt

> looks like its comma delimited.

Interesting; why wouldn't you use `head`? Who knows how big textfile.txt is?

generally, speaking, if you don't have an idea of how big the file is, or it would take up too much real-estate on your terminal window, sure. 100%. It was just an example.

lot's of times we sort of know what we are working with, but don't remember the particulars especially

Don't forget to pipe head into 'cat -v'... that text file could contain _anything_!

Thank you for pointing this out! This is much safer.

I really recommend folks use "less" over cat, especially keyboard oriented folks. Different terminal emulators don't always have the scroll behavior I want, not do they always allow me to search the file I'm looking at. "less" does all those things, in nearly every environment no matter the terminal emulator, and has other wonderful options to boot (chop long lines so they don't wrap can be nice for logs, line numbers can be VITAL, etc).

I still uselessly use cat though, it's such a nice way to build a pipeline.

My useless cat is that I always use `cat file | less` when I could just `less file`.

I've been typing cat for over 25 years. Old habits die hard.

I hate that when I use `less`, then quit, the output goes away.

You can run "less -X" for that, but it may have other problems depending on how you use less (e.g. scrolling up, etc.)

`file` will tell you too

Won't tell you the delimiter.

You could consider

    < foo.json jq | pbcopy

I've been using bat as a cat replacement for a while now. It includes paging, syntax highlighting, line numbers, and is generally very performant.

https://github.com/sharkdp/bat

If you're using zsh, you can just replace any instance of

    $ cat somefile ...

with

    $ <somefile ...

For bash, this only works if you have at least one `|`.

I did this last time I saw it come up and was surprised! Doing it makes perfect sense in hindsight. Neato!

As a scientist who cares about reproducibility, the big difference between the "useless cat" and providing the input file name on the command line is that, in the latter case, the program can capture that file name and reproduce it. That is harder when using stdin.

Many of my programs and scripts start output with the line: # cmd arg1 arg2 arg3 ...

and simply echo back lines that start with '#'. That way, I have an internal record of the program that was run and the data file that was read (as well as previous parts of the analysis chain).

And, 'R' ignores lines starting with '#', so the record is there, but does not affect later analyses.

In what way do you see those alternatives as superior?

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)

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...

>They avoid an unnecessary invocation of the cat executable.

And ... ?

I teach shell scripting. Cat invocations are cheap and help learners understand and keep clear where input is coming from, and where it is going. There are no awards or benefits to reducing the number of lines, commands invoked, or finding the shortest possible way to perform a task in a script. There are plenty of detriments to reading and understanding though when we try to obfuscate this to save 1ms of execution time on a script that is going to execute near instantaneously anyways.

In short, I straight up don't care.

I 100% agree with you. My only defense of OP is that `<` is something tends to be forgotten. Like everyone else in this thread I go to `cat` first for things like this. But sometimes I forget that even `<` exists, and the callout is a nice reminder.

If the command is meant to stream through something really fast by using a large buffer size, then prepending a cat(1) will limit the incoming buffer size to ~4k.

Interesting.

Maybe use dd with one of its blocksize options, then?

Not at a terminal, can't check.

It usually doesn't matter much, but there are some situations where it can matter a lot. For one thing, you can't use seek() on a pipe, so e.g. `cat bigfile | tail` has to read through the entire file to find the end, but `tail bigfile` will read the file backward from the end, completely skipping the irrelevant beginning and middle. With `pv bigfile | whatever`, pv (which is basically a pipeline progress indicator) can tell how big file is and tell you how for through you are as a percentage; with `cat bigfile | pv | whatever`, it has no idea (unless you add a flag to tell it). Also, `cat bigfile | head` will end up killing cat with a SIGPIPE signal after head exits; if you're using something like "Unofficial bash strict mode" [1], this will cause your script to exit prematurely.

Another sometimes-important difference is that if there are multiple input files, `somecommand file1 file2 file3` can tell what data is coming from which file; with `cat file1 file2 file3 | somecommand` they're all mashed together, and the program has no idea what's coming from where.

In general, though, I think it's mostly a matter of people's expertise level in using the shell. If you're a beginner, it makes sense to learn one very general way to do things (`cat |`), and use it everywhere. But as you gain expertise, you learn other ways of doing it, and will choose the best method for each specific situation. While `cat |` is usually an ok method to read from a file, it's almost never the best method, so expert shell users will almost never use it.

[1] http://redsymbol.net/articles/unofficial-bash-strict-mode/

The “useless cat” meme needs to die. Everyone is aware that most commands accept a file argument, but looking up the arguments and their ordering is annoying and using cat for things like this is just fine.

The redirect always works though - that is not a program argument, that is handled by the shell. Apparently not everyone is aware of that.

This. "Useless cat" is more useful than "useless file-arg".

granted, it is a little snarky and maybe the snark isn't appropriate in today's tech environment. but no, things like "useless use of cat" do not need to go away, because they make me better at what I do in little ways. those little ways add up over time.

> but looking up the arguments and their ordering is annoying

you seem to be arguing for complacency. taking your idea to an extreme, why learn to do _anything_ well?

Everyone is not aware, new people are joining all the time.

Is there any shell that has cat as a built-in?

Such a shell could remove some of the more common cases.

All of them do. Including bash. It’s just not the same syntax (ie ‘< filename’).

But I honestly think people who try to optimise away ‘cat’ are optimising the wrong thing. If one extra fork() is that detrimental then don’t use a shell scripting language.

For a lot of people, “useless” ‘cat’ enables them to write a pipeline in the order that their brain farts out the requirements for the pipeline. So they’ve optimised for human productivity. And given the human brain is slower than a few extra fork()s, I think optimising for one’s brain makes more sense here.

> All of them do. Including bash.

Are you sure? https://unix.stackexchange.com/questions/208615/is-cat-a-she... disagrees and neither https://manpages.ubuntu.com/manpages/jammy/man7/bash-builtin... nor https://zsh.sourceforge.io/Doc/Release/Shell-Builtin-Command... mention it

Literally the next sentence after the one you quoted explains my point:

> It’s just not the same syntax (ie ‘< filename’).

Reading from a file isn’t a hard problem. Having a good UX for doing that is where most shells fall apart. And that’s basically what ‘cat’ offers here: an improved UX.

Having ‘cat’ as a shell builtin wouldn’t really solve the complaints raised by “useless use of” anyway because you’d still be piping (and in some cases, fork()ing too). You couldnt really use ‘cat’ as syntactic sugar for ‘<‘ because things start to get really weird if you want to pass flags to ‘cat’ or even redirect the output to something other than a pipe. And given ‘cat’ is POSIX (https://en.m.wikipedia.org/wiki/List_of_Unix_commands#/media...) the current behaviour of shells is, in my opinion, correct. This is why my own shell has a differently named builtin that approximately serves the purpose of ‘cat’ but for instances when you need the command built into the shell and it can’t just be passing a file handle to the next command (in my case, because i wanted to pass metadata out-of-band as well as the file contents)

On Linux I have these wrap xsel or xclip, and likewise open to xdg-open.

Now, for your Mac example — if that's a specific pipeline you often use, you can write a Service menu entry to do it in place, without switching to a terminal.

+1 to the service menu actions. They are so handy, but often forgotten/overlooked. I think maybe a discoverability issue.

I love this flow! Such a powerful and clean way to solve text issues.

    # This will remove Windows double-spaced empty lines from your copy/paste buffer
    alias winlines="sed '/^$/{$!{N;s/\n//;};}'"
    
    # pbw = [P]aste [B]uffer to fix [W]indows line endings
    alias pbw="pbpaste | winlines | pbcopy"

Also - if you want `pbpaste` and `pbcopy` on Linux...

    # imitate MacOS's paste buffer copy/paste:
    alias pbcopy='xsel --clipboard --input'
    alias pbpaste='xsel --clipboard --output'

Here's the xclip way (almost the same actually).

    alias pbcopy="xclip -selection clipboard"
    alias pbpaste="xclip -selection clipboard -o"

I use this, and another Mac affordance I copy in Linux is

    alias open="xdg-open"

There's `wl-copy` and `wl-paste` for Wayland users too, via https://github.com/bugaevc/wl-clipboard

And `cb` which works cross-platform, via https://github.com/Slackadays/clipboard

I don't remember when I learned about these, but they've been game changers, and everyone I've shared them with feels the same way. I use your use case often as well, though through `jq` because I'm more familiar with it, and sometimes wish to do transforms.

You can use `python -m json.tool` for just JSON formatting, which is convenient now that Python is available by default in most Linux distros. Jq is really excellent though.

I have linux/macos-agnostic bash functions in my dotfiles that unify this to “clip” and “paste” (since “copy” is too close semantically to “cp”)

paste(1) is a POSIX standard utility, though (going back to System III), pairing with cut(1).

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p...

The Unix join command is also useful:

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

And I have one that unifies _both_ to `clip` so you can put the same command in both sides of the pipe, e. g. to turn a line-delimited blob on your clipboard to a space-separated one:

    clip | tr '\n' ' ' | clip

https://github.com/svieira/dotfiles/blob/a3654d6a194e3689978...

    # Use clipboard in shell pipelines
    # clip | xargs echo           # uses pbpaste
    # ps -A | grep search | clip  # uses pbcopy
    clip() {
      [ -t 0 ] && pbpaste || pbcopy
    }

Holy crap. Of course! You win! Amazing!

Simple is genius

So to check if there's anything sitting on stdin without reading it I've been using

`if read -r -t0; then` # returns true if there is data but times out instantly so it doesn't consume any

Is `[ -t 0 ]` more idiomatic? Apparently it fails on this case: function < file

`read -r -t0` is Bash-only though and not POSIX, but it will work regardless of what type of data is on stdin

[ -t 0 ] instead checks whether stdin (fd 0) is a tty.

Extra handy when combined with `piknik`[1] for distributed/cross-Apple account clipboard shenanigans.

[1] https://github.com/jedisct1/piknik

I like to use `pbcopy` when exporting public keys to external services like GitHub.

`cat ~/.ssh/mykey.pub | pbcopy`

I love this tool too!

except one time I quickly typed

`cat ~/.ssh/mykey | pbcopy`

And sent it straight away to my coworker on Slack.

I then spent the rest of the day making a new private key and adding my new pubkey to all of the 1000+ servers I had root access to. I mean we had tools to help but it still wasn’t fun.

With great power/convenience comes the potential to do dumb things at lightning speeds!

I might start naming my private key files ~/.ssh/keyname.PRIVATE after hearing that story...

That's not a bad idea. I've never actually made the same mistake, but I have caught it at the last moment and having tab complete not pick the private one first would help.

It would have avoided it! I was using tab and forgot to select .pub as you correctly surmised. I was a junior dev at the time and all the seniors got a good laugh out of it, and I use it as a cautionary tale about trying to be TOO overeager and efficient.

Userify would have made that pretty painless (all it really seems to do is update the authorized_keys across all of your servers every minute or so)

also userify allows you to set up sudo access on some of the servers and not others, so that'd take care of the other root-access issue you have. (sudo also provides auditing/logging controls that are useful in a multi-user environment)

If you literally have ssh root access to 1000+ servers, using certificates will be more secure and convenient than directly using public key.

put your private key in something like Secretive: https://github.com/maxgoedjen/secretive

You can even simplify this further by feeding `pbcopy` the key directly using file redirection instead of a pipe:

`pbcopy < ~/.ssh/mykey.pub`

(I use this all the time myself!)

Where are you pasting the pretty json to view it?

I do this a lot as well, but just paste the minified json directly into VS Code and then OPT+SHIFT+F to format it.

`jq` acts as a pretty json viewer (among other things)

Those are so useful that I wrote trivial shell functions that do the same under Linux.

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.

Yes. I use it a great deal, but I haven't gotten used to using the linux equivalents. I guess that would be either xsel or xclip. Maybe I should create a "pbcopy" that runs one of those. I like to minimize the cognitive load when I switch between mac and linux command line environments.

Another frequent use I have, applying random diffs with git:

    git diff | pbcopy
    pbpaste | git apply

* * *

I should use `git format-patch` instead of creating a mock draft PR (which I end up deleting) and modifying the URL to add `.patch` and then downloading the patch file haha. `git format-patch` would probably be faster :)

alias pbg='pbpaste | fgrep --color -i "`pbpaste -pboard find`"'

select all in a terminal window with pages of log data and cmd-c copy; find the one phrase you want to find in that data and cmd-e to put it in the find pasteboard; cmd-n new window, type pbg to isolate the log lines.

TIL about named pasteboards https://developer.apple.com/documentation/appkit/nspasteboar...

I recognize that your pbg alias works for pretty much any text you could copy, but I wanted to mention, in case you're looking at log files with plain old less, there's the & limiter, which limits the current view to only lines matching a regular expression (or, if you type ^R during a & prompt, for a text match).

If you type ^N or ! during a & prompt it will limit the view to those lines that do not match the expression.

These view limits stack, so you can "&WARN<enter>" to see all lines that have WARN in them, and then maybe you want to see just a certain PID so "&12345<enter>" and you'll only see lines with both WARN and 12345, but then that one module is printing out a bunch of messages you think are safe to ignore so you do "&!modulename<enter>" and it filters out log lines that match modulename. Very handy and less is everywhere.

Oh man. I recently threw together a "j2p" script to make converting between json and python dicts simpler, and combining it with pbcopy/pbpaste will make it so much better:

  #!/usr/bin/env python3
  import sys
  import json
  
  print(json.load(sys.stdin))

* * *

The Python json library is callable as a module:

    pbcopy | python -m json.tool | pbpaste

It has a load options:

    $ python -m json.tool --help
    usage: python -m json.tool [-h] [--sort-keys] [--no-ensure-ascii] [--json-lines] [--indent INDENT | --tab | --no-indent | --compact] [infile] [outfile]

    A simple command line interface for json module to validate and pretty-print JSON objects.

    positional arguments:
      infile             a JSON file to be validated or pretty-printed
      outfile            write the output of infile to outfile

    options:
      -h, --help         show this help message and exit
      --sort-keys        sort the output of dictionaries alphabetically by key
      --no-ensure-ascii  disable escaping of non-ASCII characters
      --json-lines       parse input using the JSON Lines format. Use with --no-indent or --compact to produce valid JSON Lines output.
      --indent INDENT    separate items with newlines and use this number of spaces for indentation
      --tab              separate items with newlines and use tabs for indentation
      --no-indent        separate items with spaces rather than newlines
      --compact          suppress all whitespace separation (most compact)

It's cool to use pbcopy and pbpaste with your phone! Copy some text on the phone, and you can pbpaste it onto the Mac command line. So cool.

It creeps me out when the clipboard is unexpectedly shared between my phone and computer. And since the feature seems to turn on randomly but not reliably when I want it to, I’d rather it just didn’t exist.

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.

Integration is the primary reason I enjoy using Apple ecosystem. My phone, laptop, tablet and watch all work seamlessly together.

I use most of Apple's "built in" applications like Mail, Notes, Photos, etc. with Firefox (instead of Safari) probably the only exception to that.

It’s wonderful when it works. For reasons beyond my comprehension, the Watch unlock for my Mac only works ~10% of the time.

There’s a fix for it where you remove all the unlock entries in Keychain, and then re-enable it. Only thing that worked for me long term (but it did fix it 100%)

https://georgegarside.com/blog/macos/fix-apple-watch-auto-un...

I tried this yesterday. It... helped. But what I've now found is that if I escape out of the password prompt (which will turn the screen off again) and then try to unlock it a second time, the watch unlock will be triggered. I wonder if it's something about waking from sleep. (I also wonder if it would have worked before to do the same thing, but it never occurred to me to try.)

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).

Wonder how many of us are out there!? Long live this app and workflow, iCloud sync ftw.

Yes, I use this app multiple times a day, each time with the added satisfaction of knowing I own the app and not a subscription. Even if my credit card expires I will still have access to my passwords.

I’m on the same version of 1password, probably for similar reasons.

In their iOS app, there’s an entry in Settings -> Security -> Allow Universal Clipboard which lets you opt-in to passwords through the clipboard. I suspect there’s something similar on macOS.

> is unexpectedly shared between my phone and computer

There was a prompt asking if I wanted to enable it, when I set up my phone/Mac. Same setup screen that asks if you want to enable location, Siri, etc.

I have a clipboard manager application called "Paste" (creative i know). Its an awesome app for a million reasons. But one thing I like is that it allows me to see and hear when my iphone copy worked.

So I have it enabled so there is a sound when something goes into the clipboard. Even on my mac, I have come to rely on that audio feedback. But it has the added benefit that when I am using my phone in front of my computer and I copy something on my phone, I immediate (and it is impressively fast... maybe a 200ms delay), I hear the chime that something was added to my clipboard on my mac. So it gives you that good feedback that a copy "worked".

You can also shift+cmd+V to see the clipboard history, which is another complimentary tool with universal clipboard because if a paste isn't working as expected you can see if the universal copy never "took" (as you mentioned it is semi-unreliable), or if it just got overridden. You can then use the navigator to paste the older item.

I wonder if it's this one: https://apps.apple.com/us/app/paste-clipboard-manager/id9678...

I've noticed that more and more apps on both macOS and iOS sniff the clipboard contents and randomly clobber it. I usually notice it in apps like Sourcetree, where I'll click something or do a certain action and suddenly I can't paste anymore. I even get a feel for it, like my mind detects the pattern that empties the clipboard so I sense when I can no longer paste, but I can't figure out concrete repeatable steps to make it happen. On iOS it's more random, and I feel like it's probably Facebook doing it, or maybe websites in Safari. I just assume that everything is spying on my clipboard contents now, hoping to log secrets/passwords and PII to sell to scammers.

I have to say, this is one of the more disappointing developments from Apple, that they certainly must know by now about these clipboard shenanigans, but have done nothing to stop them. They need to implement permissions that deny all apps the ability to get/set the clipboard by default, and have an option to ask the user whether so-and-so app can access the clipboard (outside of normal copy/paste), every time with the option to allow always. And all clipboard access attempts should probably get logged somewhere.

I think iOS now has per-app permissions/notifications around clipboard reads.

I would think requiring opt-in for clipboard functionality would be the more radical option that would leave most users (myself included, I would imagine) scratching their heads when they can’t copy/paste as a matter of course. Maybe you meant something more specifically related to 3rd-party sniffing/modifying clipboard contents, but I haven’t really encountered that outside of apps such as CopyQ and Paste, and they are pretty explicit and intentional about their functions.

I have found a lot of utility with cross-device copy/paste. I know it requires the somewhat mysterious phantom Bluetooth/Wi-Fi connectivity that AirPlay/Airdrop use, so if I have disabled Bluetooth on my device, for example, it will no longer work. I could see where it might not be fully reliable enough to count on, I have experienced inexplicable failures, not often but enough to understand that it might not be some folks’ default preference. As part of the “handoff” function, it can be disabled in Settings at least.

Disabling Handoff is currently the only way to disable Universal Clipboard.

* Mac: Go to System Preferences > General > uncheck Allow Handoff.

* iPhone: Go to Settings > General > Handoff > uncheck Handoff.

Make sure both your phone and computer have Wi-Fi and Bluetooth turned on.

I'm curious why the Bluetooth is required?

Requiring WiFi makes (so the phone/computer is on a network and can communicate with the other devices), but what's the benefit of Bluetooth? Does it only work when the phone and computer are near each other?

Bluetooth is used to discover peers and to initiate communication. Thus handoff works even on a wifi network that blocks broadcasts. It even works when no wifi network is present, by setting up an ad hoc network for the connection. (Disclaimer: This is all I know. The details seem rather murky, as handoff is a proprietary Apple protocol.)

The requirements are here: https://support.apple.com/en-au/HT209455

Turning off Bluetooth or wifi may be one of the more common reasons it doesn’t work. Some people never do that, but others do.

Yes.

Use the Apple shortcuts app and you can just copy some text and hit a keyboard shortcut. The Shortcuts app lets you run arbitrary shell command.

This is interesting, thank you. I've been automating various things with Hammerspoon but (I think) it's limited to what you can reach with either a11y or osascript / the NS dictionary for the app you want to manipulate, but Shortcuts seems to have some actions that aren't in the NS dictionary.

For instance, in Shortcuts, I see that there's a "Pin Notes" action for Notes.app, but I don't see anything for pinning notes when I open Notes.app with "File -> Open Dictionary..." in Script Editor.

(In this case it's likely that Notes.app has the a11y bits necessary to run that action from Hammerspoon, but it would probably be easier to go through Shortcuts.)

Json pretty printing in the terminal? Bless, didn't know about that and it is perfect

pb[paste|copy] are a life improver. Here is a one-liner to edit the pasteboard contents in vim.

  pbpaste > tmp; vim tmp; cat tmp | pbcopy; rm tmp;

I also use pbpaste to append various notes to files, but since pbpaste doesnt have a newline at the end I wind up using:

  echo "$(pbpaste)" >> notes.txt

You can do this specific task with just vim: https://vi.stackexchange.com/a/21448

Also a fun one to combine with `open` if you have a bunch of web URLs to open

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.

That’s a great hack thanks for the tip.

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

So much of my Linux use is over ssh from a MacOS client that I've made a `pbcopy` executable that just pipes stdin over ssh to my MacBook to its pbcopy (with a dedicated ssh key that runs this as a forced command). Makes it super nice to be on an SSH session and `pbcopy` some content to my MacOS clipboard!

That sounds amazing, I always wanted to do that! Do you have a guide or some script to help with it? Otherwise, I will try to do it on my own.

Happy to share, but I'm away from my MacBook for the next 2-3 weeks. I'll ping you when I have access to the code again.

I'm also super interested in this! I've had many amusing moments of instinctively typing either `pbcopy` or `pbpaste` on remote boxes followed by a brief moment of confusion when my local clipboard isn't updated :)

You might want to have a look at osc52

I have! Unfortunately not supported in MacOS Terminal.app, which I'm otherwise very satisfied with (have tried iTerm2, use Alacritty on Linux, just like Terminal.app).

Simply wrap your shell with osc52pty to get OSC52 support in Terminal.app

https://github.com/roy2220/osc52pty

I don't think wrapping my entire shell session in a moderately complex third party tool (that maybe just uses pbcopy under the hood[1]) counts as "simply" when compared to my existing solution which just pipes over ssh and a couple bash scripts.

But thank you for the share, it is interesting!

[1]: https://github.com/roy2220/osc52pty/blob/master/oscexecutor....

This tool isn’t doing anything particularly complex. It sets up a new pty, attaches the child process to it, listens for OSC52 control codes, and calls pbcopy when appropriate.

You can wrap your ssh session with it and you’re done.

It’s very elegant and multiple orders of magnitude less complex than something like tmux.

I use the following to edit contents of my clipboard:

    pbpaste | vipe | pbcopy

Where vipe is a util for inserting your editor (vim) in the middle of a pipe. From: https://joeyh.name/code/moreutils/

This is great utility I didn't know about! Thanks!

But do you know why it doesn't seem to work with the `pbfilter` function?

If I do directly `pbpaste | vipe | pbcopy`, then it opens vim and the clipboard text is pasted there. But if I run `pbfilter | vipe`, then vim opens with a blank buffer.

   function pbfilter() {
      if [ $# -gt 0 ]; then
          pbpaste | "$@" | pbcopy
      else
          pbpaste | pbcopy
      fi
   }      

It seems that the number of args is 0 for some reason

I think you have to use `pbfilter vipe`, as the argument to pbfilter is inserted into the middle of the pipe.

I find that the `pbpaste | something | pbcopy` idiom is common enough that it's worth having a shell function for it:

  pbfilter() {
      if [ $# -gt 0 ]; then
          pbpaste | "$@" | pbcopy
      else
          pbpaste | pbcopy
      fi
  }       

Then you can use something like `pbfilter json_pp` or `pbfilter base64 -d` or `pbfilter sed 's/this/that/'` or whatever.

This version also can also act as a plain-text-only filter. If you just use `pbfilter` with no argument, it'll remove any formatting from the text in the pasteboard, leaving just straight plain text.

It does have a some limitations, though: you can't use it with an alias, or pipeline, or anything complex like that. The filter command must be a single regular command (or function) and its arguments.

I've aliased that (and its equivalents on Linux and Android/Termux) to 'xc' and 'xp' (for X11 Copy and X11 Paste, as I'd originated this on Linux).

Being able to populate or read from the system clipboard (or secondary clipboard!), or to feed it, including by reading from or writing to pipes is wonderful.

I have an alias that while trivally simple is quicker to type and remember. It copies whatever file you give it to the clipboard which is super handy. I use it with the "Compare with Clipboard" to diff a file in Rubymine for example.

alias clip='pbcopy <'

Best way to get ssh keys into the paste buffer too.

my favorite vim command:

:w !pbcopy

or visual selection, and then :w !pbcopy