[HN Gopher] Clipboard: Cut, copy, and paste anything, anywhere, ...
___________________________________________________________________
Clipboard: Cut, copy, and paste anything, anywhere, all from the
terminal
Author : thunderbong
Score : 170 points
Date : 2022-12-27 03:28 UTC (19 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| omgtehlion wrote:
| On windows there is already a built-in clip.exe
| (https://ss64.com/nt/clip.html) which was there like forever...
|
| But it is nice to have this tool with more functionality on all
| platforms in unified way!
| notimpotent wrote:
| I discovered this just the other day and could not believe it
| had been there all along!
| photoGrant wrote:
| I wish there was a tool that allowed me to send my clipboard to a
| server and anytime I sent something to the clipboard it checks
| the ssh hosts file for the config and sends it off. I'd like to
| 'paste' on any other machine with an ssh command.
| brasic wrote:
| I use https://github.com/BlakeWilliams/remote-development-
| manager for this, which works by running a server and
| forwarding its socket over the SSH connection. If you're
| willing to add some aliases and editor/ssh config you can
| easily get a UX that feels like a unified clipboard across
| remote hosts. My favorite use is integrating the yank buffer of
| remote vim processes with my local system clipboard.
| zenosmosis wrote:
| This is interesting, I'd like something like that as well.
|
| I'm doing some experimentation with something sort of along
| these lines via WebRTC.
| [deleted]
| nikvdp wrote:
| I keep a cobbled together version of something like this in my
| rc files. The ui mimics macOS's pbcopy/pbpaste commands (it
| degrades gracefully on linux boxes too by falling back to xsel
| if available, and then to a tmp file for use on headless
| servers).
|
| The special sauce is that you can put a server name from your
| ssh config on the end of a pbcopy or pbpaste command so you can
| do stuff like run `echo hello | pbcopy server2` on server1,
| after which doing `pbpaste` from server2 would print 'hello'.
| You can also do this in the other direction with pbpaste, eg
| from server2 you can run `pbpaste server1` and it'll print out
| the contents of server1's clipboard.
|
| The current setup is a bit coupled to my rc files, but if
| there's interest would be glad to refactor a bit and toss it on
| github
| maneesh wrote:
| Very interested
| codetrotter wrote:
| > if there's interest would be glad to refactor a bit and
| toss it on github
|
| Even just upload it in its current state would be nice :)
| photoGrant wrote:
| yep, I want this and you're half way there!
| nikvdp wrote:
| what's the missing half? file transfer?
| photoGrant wrote:
| I'd like to do this with a client/server routine where
| the server will spit out to any client connected with a
| tunnel
| jedisct1 wrote:
| There's Piknik: https://github.com/jedisct1/piknik
| photoGrant wrote:
| Looks exactly it!
| krisgenre wrote:
| Though not exactly the same, I did create a project for easy
| sharing of clipboard
| https://github.com/krishnaraj/oneclipboard. Lost interest after
| background Clipboard access was restricted in Android 10 or
| something.
| meitham wrote:
| OSC 52 can do that, even for iPhone Blink terminal
| ptspts wrote:
| Where is the actual, platform-specific business logic in the
| source code of this software?
|
| All I was able to find was
| https://github.com/Slackadays/Clipboard/blob/6fd7e6b695ebe57... ,
| which opens the X11 connection -- but where does it actually
| read/write the selection (clipboard)?
| netr0ute wrote:
| It doesn't exist yet, the current code is just WIP.
| cormacrelf wrote:
| > Clipboard works on any up-to-date Windows, Linux, Android,
| macOS, FreeBSD, OpenBSD, NetBSD, DragonFlyBSD, or OpenIndiana
| system, or anything that supports C++20, all with ZERO
| dependencies. Yes, really!
| netr0ute wrote:
| It doesn't have any dependencies, as it checks for X11 or
| Wayland library availability upon compilation and gets rid
| of any X11/Wayland code if those libraries aren't found.
| 3np wrote:
| tmux (on workstation) integrates naturally with system clipboard
| and after finally getting it into my workflow, none of the
| annoyances in the readme anymore. It Just Works.
|
| Defaults with vi keys: Leader+[: enter selection
| mode Space: start selection Return: copy selection
| Leader+]: paste
|
| If you enable mouse in tmux, you just select to copy.
|
| Then xsel -b / xclip -sel clip, or wl-clipboard for cli.
|
| You could integrate it in vim as well but personally I like to
| keep that separate.
| [deleted]
| puffybuf wrote:
| I'm curious how this is implemented to work with all the
| different window systems without dependencies. edit: OK I looked
| at the source code, it does actually include the windowing system
| headers and use the base libraries.
|
| I'm glad there are people not afraid to use the latest version of
| programming language features. I always try to use C++20 for new
| projects, but often the dependencies prevent me.
|
| If you want to use the clipboard from cmdline you can also use
|
| xclip (for Xorg)
|
| wl-clipboard (for wayland)
|
| and on macOS you can use the builtin commands: pbpaste pbcopy
| (see the man page)
|
| These are what I've been using, but I might change now.
| pimlottc wrote:
| > xclip (for Xorg)
|
| There's also xsel as a long time utility for Xorg as well.
| suketk wrote:
| > echo "yo mama" | cb
|
| > cb > really_large_objects.txt
|
| Did not expect that.
| [deleted]
| tarkin2 wrote:
| Is there a clipboard I can use without installing X or Wayland
| yet?
|
| Tmux and GNU screen have their own copy buffers but they're not
| so useful when you're copying text from separate vim instances,
| scrolling both up and down in vim.
| netr0ute wrote:
| > Is there a clipboard I can use without installing X or
| Wayland yet?
|
| You're looking at it right now.
| jinnko wrote:
| See other posts here about OSC 52
| res0nat0r wrote:
| On OSX you can do something a little less fancy with pbcopy |
| pbpaste. I normally use it to copy text from files to an email /
| url output etc.
| hboon wrote:
| And I've used this for a few years, courtesy of
| https://news.ycombinator.com/item?id=10145362
|
| I added the call to `ansifilter`:
|
| function clip
|
| if not tty >/dev/null ansifilter | pbcopy
| else pbpaste end
|
| end
| locusofself wrote:
| This looks neat, but as someone who doesn't use Linux on the
| desktop, I'm typically fine with
|
| macOS (zsh/bash): command | pbcopy
|
| windows (powershell) command | Set-Clipboard
| charlesdaniels wrote:
| I wrote a wrapper around these some years ago which I've been
| using since. It's been working pretty well for me.
|
| https://git.sr.ht/~charles/dotfiles/tree/171c95a20394552e02a...
| krick wrote:
| alias pbcopy='xclip -selection clipboard'
|
| alias pbpaste='xclip -selection clipboard -o'
| [deleted]
| jvanderbot wrote:
| The same flow for Linux can be had with 'xsel'
| rubicks wrote:
| It sure can:
|
| alias pbcopy='xsel --clipboard --input'
|
| alias pbpaste='xsel --clipboard --output'
| mrich wrote:
| I'm still looking for a way to transfer text from a remote server
| in VS Code to the local system. Anyone have that?
| kristopolous wrote:
| In Linux this is trivial.
|
| There's a number of clipboard management and inspection tools
| such as xclip and you can bind keys to do arbitrary commands
| with a bunch of tools.
|
| There's a wide variety of ways to send stuff over the network
| as well.
|
| The architecture is pretty obvious
|
| Copy on remote, clipboard manager emits over network, local
| server picks up text, puts in clipboard.
|
| This is like a few hours at most
| layer8 wrote:
| The documentation is silent on how it interacts with the system
| clipboard. I would have expected the _Compatibility_ section to
| address this.
|
| Does it work on Cygwin (which has /dev/clipboard)?
| odiroot wrote:
| From a quick scan of the source, it should support Wayland. But
| the binary from the releases doesn't seem to. I presume it was
| compiled with only Xorg support.
| netr0ute wrote:
| Clipboard doesn't have support for either Xorg or Wayland yet,
| but the headers are already included to make it easier to add
| when it's ready. I know this because I wrote Clipboard (check
| my submissions)
| franga2000 wrote:
| In that case please add that to the README. "copy anything
| anywhere" and "supports any up to date Linux" are blatant
| lies
| netr0ute wrote:
| Those are based on the goals of the project, not where it
| currently is (see the 0.1.3 version number)
| yjftsjthsd-h wrote:
| Then the readme should say that, because it currently
| presents itself as being a complete and functional
| solution. In fact, the readme only mentions Windows
| support as being WIP, which implies that everything else
| isn't. And the version number doesn't tell us anything
| about functional completeness; people frequently use 0.x
| only to mean that they're not committing to any stability
| guarantees.
| DiabloD3 wrote:
| So why not just use OSC 52, which is built into most terminals?
| The functionality required already exists.
| farrelle25 wrote:
| Yes OSC 52 is very handy for vim over SSH: instead of X11
| forwarding - you can just yank text from remote vim into the
| local clipboard using OSC 52 [1].
|
| Overall it's much quicker - as yanking in vim with X11
| forwarding and '+clipboard' sometimes had a delay.
|
| (ps: I think OSC 52 is implemented in xterm and URXVT, but not
| yet in gnome-terminal)
|
| [1]: https://github.com/ojroques/vim-oscyank
| loloquwowndueo wrote:
| On Debian derivatives, vim-gtk is built with X clipboard support
| via the " register. +"yy will yank the current line to the X
| clipboard and so on. Note vim-gtk does not force you to use the
| gtk version; the terminal version it includes (which replaces the
| usual one via alternatives) also has " support.
| jvanderbot wrote:
| I use xsel for CLI stuff. You may want to check it out and add
| it to your toolbox
| loloquwowndueo wrote:
| Thanks! I know about it and use it as well :) just not
| necessary when working in vim which covers most of my needs.
| omani wrote:
| a similar tool is https://github.com/brunelli/wl-clipboard-x11
| and xclip (for Xorg).
| klabb3 wrote:
| Clipboard is one of few prime candidates for a "flip the table
| and start over from scratch" -style revolution. Almost everything
| about it sucks: it's largely vendor/platform/distro/window-
| manager (heck even text-editor) specific. It has a huge amount of
| accumulated complexity, it has security issues, and yet it's not
| flexible enough for power use cases like multiple clipboards..
| and non-technical users struggle a lot with simple cases.
|
| It's so frequently used it deserves prime physical real estate of
| one or two dedicated keys. It deserves a standardized API for at
| least image data, text, files, and an extension system, that
| works the same across platforms. Most importantly it needs
| discoverable, inspectable consistent UX that can be taught in
| schools and to seniors.
|
| I'm not saying it's easy, clipboard is almost by definition
| shared mutable state, which is hard and messy. Then it needs to
| work with touch screens, cli and maybe even other interfaces. And
| its closely related cousins, like drag and drop and selections,
| are also important and related UX considerations.
|
| Disclaimer: I'm a little bit intentionally provocative, and I
| should probably really be more careful what I wish for, since any
| major change inevitably runs into (major) problems (see exhibit A
| - ipv6). I am partly just venting - after all these decades we
| certainly have enough experience to build something better. We
| certainly deserve it.
| [deleted]
| [deleted]
| jimmySixDOF wrote:
| Yes - bang for the buck, you probably couldn't do much better
| than improving some part of cut/copy/paste/drag/drop. I think
| what's needed is an inverted Infinate Canvas approach with ring
| fenced buckets for each copy/cut event. I sort of use that now
| keeping a web service page open on multiple machines to
| push/pull through.
| 1vuio0pswjnm7 wrote:
| What is the difference between "the terminal" and the "terminal
| emulator".
|
| This appears to be for the terminal emulator. I gave up on X11
| and its successors many years ago in favor of what was called, at
| the time, "VGA textmode". No framebuffer, unfortunately. Have not
| used a mouse outside of work in thirty years. "Clips" for me are
| captured (copied) from pipes or from pseudo-terminals, saved in
| buffers and pasted into pipes and pseudo-terminals.
|
| A "terminal multiplexer", i.e., tmux, is the solution I use as a
| "clipboard", namely what tmux calls "saved buffers". Specifically
| the commands I use are load-buffer, save-buffer, paste-buffer,
| list-buffers and delete-buffer.
|
| So what the heck is "the terminal". The way HN commenters use the
| term it probably means "the terminal emulator". But perhaps it is
| an umbrella term for textmode, multiplexer and emulator.
| imiric wrote:
| You're being pointlessly pedantic.
|
| It's pretty clear what "terminal" means in this context. Nobody
| uses the term in the classical mainframe sense, so "emulator"
| is implied.
|
| And you brought up "multiplexer". It's neat that you use it for
| clipboard management, but this tool does much more than that.
| 1vuio0pswjnm7 wrote:
| Userspace replacement for Linux kernel-provided virtual
| consoles/terminals
|
| https://cgit.freedesktop.org/~dvdhrm/kmscon/plain/README
| dsr_ wrote:
| Your text mode console is also a terminal emulator, albeit one
| provided by the kernel.
|
| Very few people use hardware terminals; the scarcity has driven
| prices up to the point where it is sometimes cheaper to get a
| full computer, monitor, keyboard and serial adapter than to buy
| a working VT-series terminal.
| blsummer wrote:
| Similar tool support Windows and OSX:
| https://github.com/b1tg/pickup
| salzig wrote:
| Not needed for MacOS, there is already pbcopy and pbpaste.
| blsummer wrote:
| There are some differences: pbcopy copy data from stdin ,
| `Clipboard` and `pickup` copy file to clipboard like right
| click copy.
| weitzj wrote:
| Interesting. Currently I use https://hluk.github.io/CopyQ/ but I
| would be happy to optimize my workflow and look for a good
| integration in sway/wayland and possibly dmenu.
|
| xsel kind of works but I would like to copy paste anything
| quanticle wrote:
| From the Clipboard "User Experience Manifesto" [1]:
| Clipboard does not have any configuration. Note that I said
| "have," not "use." That's because Clipboard cleverly
| picks up on certain settings that are present everywhere
| they're possibly used. One such setting is NO_COLOR.
| NO_COLOR is an unofficial standard to specify a global disabling
| of color output by software. If the NO_COLOR environment variable
| is defined, then programs should not display color.
|
| I'm unaware of many programs that actually respect $NO_COLOR.
| Certainly `ls` and `grep`, the two programs I use the most which
| display colored output, don't respect that environment variable.
| `ag` doesn't respect it either. In fact, the only program I use
| on a semi-regular basis which respects $NO_COLOR is `fd`. All the
| rest expect a `--no-color` command line parameter to disable
| colorized output. Given that, I'm wondering why the authors chose
| to control output colorization with an environment variable,
| rather than a command line argument.
|
| [1]: https://github.com/Slackadays/Clipboard/wiki/User-
| Experience...
| augusto-moura wrote:
| Origin of NO_COLOR [1] and relevant discussion on HN [2]
|
| [1]: https://no-color.org/
|
| [2]: https://news.ycombinator.com/item?id=30483417
| gizmo686 wrote:
| Neither ls nor grep output color by default. Most distributions
| have a bashrc script that sets aliases like:
| alias grep='grep --color=auto' alias ls='ls --color=auto'
|
| Ls and grep are defined such that you can specify --color
| multiple times and the last one will take effect, allowing you
| to disable coloring while still using the alias that enables
| it. The FAQ at no-color.org states:
|
| > User-level configuration files and per-instance command-line
| arguments should override $NO_COLOR
|
| So, it looks like like ls and grep respect it fine with just
| their default behaviour.
|
| As an aside, at least on my system, ls and grep do not
| recognize --no-color. I need to specify it with --color=never.
___________________________________________________________________
(page generated 2022-12-27 23:02 UTC)