copy and paste, under Wayland, and to and from an XTerm, was relating to dl audio and video
Hello Craig, Many thanks for your excellent posts, I am learning more. However I have Debian 10, nominally up to date, and it has Wayland with Gnome as the desktop. I am finding it very frustrating that I cannot copy and paste to and from the XTerm window. I used to be able to do with earlier terminal emulation under the XWindows system. I used it to be able to copy text from a terminal into an email, and commands back from email, ensuring that I did not make typos. I do understand that there can be security issues if used without a measure of care and thoughtful, but it also has much merit when coping with some of the regular expressions that come up as examples in email and on web pages. Regards, Mark Trickett
On Tue, Aug 18, 2020 at 04:54:08PM +1000, Mark Trickett wrote:
Many thanks for your excellent posts, I am learning more. However I have Debian 10, nominally up to date, and it has Wayland with Gnome as the desktop. I am finding it very frustrating that I cannot copy and paste to and from the XTerm window.
Sorry, i don't use Wayland, have no idea what could be going wrong with this. I can't see the point of Wayland. TBH, it seems like the systemd of X - a half-arsed crappy partial implementation of only the stuff that the devs personally use because there's no way that anyone else could ever need anything they don't use. Also, CADT syndrome: never fix anything. toss out the old garbage, make way for the shiny new garbage. Fixing bugs is boring. Reimplementing from scratch every year or two is fun and exciting and it'll be perfect. For sure, this time.
I used to be able to do with earlier terminal emulation under the XWindows system. I used it to be able to copy text from a terminal into an email, and commands back from email, ensuring that I did not make typos.
That's weird. i'd be surprised if Wayland was actually incapable of doing something as basic as copy and paste between terminal windows, so it's probably a bug or a configuration error. Maybe try a different terminal instead of xterm. There are dozens to choose from. I mostly use roxterm (full-height apart from the space used by xfce4-panel, full-width, approx 250x60 depending on font size - great for viewing log files), but sometimes I use xfce4-terminal if i want a tall, narrow window (80 or 132 x 60) to fit beside something else.
I do understand that there can be security issues if used without a measure of care and thoughtful, but it also has much merit when coping with some of the regular expressions that come up as examples in email and on web pages.
the "security issues" comes from blindly executing code/commands that you don't understand. treat everything as just an example that needs further research. never execute something posted by someone else(*) unless you know what it does and how and why. (*) ANYONE else. even if they're trustworthy and not malicious, they could be wrong, they might have made a mistake. craig -- craig sanders <cas@taz.net.au>
On Sun, 30 Aug 2020, Craig Sanders wrote:
On Tue, Aug 18, 2020 at 04:54:08PM +1000, Mark Trickett wrote:
I do understand that there can be security issues if used without a measure of care and thoughtful, but it also has much merit when coping with some of the regular expressions that come up as examples in email and on web pages.
the "security issues" comes from blindly executing code/commands that you don't understand.
treat everything as just an example that needs further research. never execute something posted by someone else(*) unless you know what it does and how and why.
It theoretically is not safe to simple paste the selection into an editor before vetting it. Through CSS and javascript, what you select in a browser and what ends up in the copy-paste buffer are frequently different. That copy paste buffer may contain ANSI-escape sequences to exit your editor and run a command directly. https://news.ycombinator.com/item?id=10554679 https://security.stackexchange.com/questions/39118/how-can-i-protect-myself-... -- Tim Connors
On 30/8/20 3:01 pm, Tim Connors via luv-main wrote:
It theoretically is not safe to simple paste the selection into an editor before vetting it. Through CSS and javascript, what you select in a browser and what ends up in the copy-paste buffer are frequently different.
I notice that XUbuntu 20.04 now has a paste preview window that shows up any time you paste data containing at least one carriage return so you can decide whether to permit the paste or block it. Very useful! Cheers, Andrew -- mailto:andrew@sericyb.com.au Andrew Pam https://sericyb.com.au/ Manager, Serious Cybernetics https://glasswings.com.au/ Partner, Glass Wings
On Sun, Aug 30, 2020 at 03:01:50PM +1000, Tim Connors wrote:
On Sun, 30 Aug 2020, Craig Sanders wrote:
the "security issues" comes from blindly executing code/commands that you don't understand.
ok, yeah, I should have started that line with "MOST OF"
treat everything as just an example that needs further research. never execute something posted by someone else(*) unless you know what it does and how and why.
It theoretically is not safe to simple paste the selection into an editor before vetting it. Through CSS and javascript, what you select in a browser and what ends up in the copy-paste buffer are frequently different.
It's true that there's a risk if you're copying from a web page (or something else that does css and/or javascript - or any kind of scripting, there's a difference between "dead" static data and active scripting, which is one of the reasons I hate over-use of javascript in the web, it's analagous to the difference between a live virus and a dead one). Especially so if you're just copying from some random site you have no reason to trust....and less so if you're copying from a well-known, mostly-trustworthy site like one of the stack-exchanges (but remember that this still doesn't protect you from errors). not true if you're copying plain text from a text mail client like mutt. also not much of a risk if instead of copy-paste, you save the email or web page or whatever to a text file and then extract what you need from the text file. craig -- craig sanders <cas@taz.net.au>
Hello Craig, On 8/30/20, Craig Sanders via luv-main <luv-main@luv.asn.au> wrote:
On Tue, Aug 18, 2020 at 04:54:08PM +1000, Mark Trickett wrote:
Many thanks for your excellent posts, I am learning more. However I have Debian 10, nominally up to date, and it has Wayland with Gnome as the desktop. I am finding it very frustrating that I cannot copy and paste to and from the XTerm window.
Sorry, i don't use Wayland, have no idea what could be going wrong with this.
I can't see the point of Wayland. TBH, it seems like the systemd of X - a half-arsed crappy partial implementation of only the stuff that the devs personally use because there's no way that anyone else could ever need anything they don't use.
I did not choose Wayland, nor systemd, but that is now the Debian defaults. There are good reasons behind the changes, or at least I have seen some support that I will concur with on why Wayland over xwindows. However I do not find benefit in systemd, the current install (Debian 10.5) is missing a piece of firmware, but I cannot read the message in time during boot, nor find it in the logs. I think it is for the network on the motherboard.
Also, CADT syndrome: never fix anything. toss out the old garbage, make way for the shiny new garbage. Fixing bugs is boring. Reimplementing from scratch every year or two is fun and exciting and it'll be perfect. For sure, this time.
I used to be able to do with earlier terminal emulation under the XWindows system. I used it to be able to copy text from a terminal into an email, and commands back from email, ensuring that I did not make typos.
That's weird. i'd be surprised if Wayland was actually incapable of doing something as basic as copy and paste between terminal windows, so it's probably a bug or a configuration error.
From my reading of pages found by a google search, there is a choice by the development team based on (in)security of casual copy and paste. I thought that it was likely a configuration issue, but cannot find. I tried a number of teminals, but not a lot, to find one that appears to be reasonable. I still need to do more research, when life leaves the time from the real world.
Maybe try a different terminal instead of xterm. There are dozens to choose from. I mostly use roxterm (full-height apart from the space used by xfce4-panel, full-width, approx 250x60 depending on font size - great for viewing log files), but sometimes I use xfce4-terminal if i want a tall, narrow window (80 or 132 x 60) to fit beside something else.
I do understand that there can be security issues if used without a measure of care and thoughtful, but it also has much merit when coping with some of the regular expressions that come up as examples in email and on web pages.
the "security issues" comes from blindly executing code/commands that you don't understand.
That is why it is not implemented, even for those of us who do carefully look over such before copying and executing. I cannot make sense of a line of perl at this time, but there are some folks I will trust, such as you and Russel Coker. I do not expect you to be perfect, but that you do know more than I, and from what I have seen, not malicious. I do try to comprehend even your examples first, but have to trust that you do know that much more in the subject of concern.
treat everything as just an example that needs further research. never execute something posted by someone else(*) unless you know what it does and how and why.
(*) ANYONE else. even if they're trustworthy and not malicious, they could be wrong, they might have made a mistake.
Anyone can make a mistake, unfortunately some people are a mistake.
craig
Regards, Mark Trickett
On Sun, Aug 30, 2020 at 05:24:39PM +1000, Mark Trickett wrote:
I did not choose Wayland, nor systemd, but that is now the Debian defaults. There are good reasons behind the changes, or at least I have seen some support that I will concur with on why Wayland over xwindows. However I do not find benefit in systemd,
most of my machines run systemd now. all but one, which just fails to boot at all if i try to boot it with systemd rather than sysvinit. I'm not entirely happy with that but i've given up fighting against it, i just don't have the energy for that. I don't actually mind systemd as an init system, i.e. starting and stopping services - it's pretty good at that. it's all the other stuff (like ntp and dns and cron) that it tries to do that pisses me off, especially since it does such a shitty job of them. I just disable as much of that systemd borg shit as I can and run the required services as extra daemons, like ntpd for ntp and unbound for dns resolution (I still use bind9 on a different IP address for serving my zones) and vixie cron.
the current install (Debian 10.5) is missing a piece of firmware, but I cannot read the message in time during boot, nor find it in the logs. I think it is for the network on the motherboard.
try something like 'journalctl -xe -b0', or 'dmesg | less'. You may be able to find the message you want by searching through that.
From my reading of pages found by a google search, there is a choice by the development team based on (in)security of casual copy and paste. I thought that it was likely a configuration issue, but cannot find. I tried a number of teminals, but not a lot, to find one that appears to be reasonable. I still need to do more research, when life leaves the time from the real world.
that would be kind of fucked up if they've disabled copy-paste into terminals or text editors entirely. so fucked up that that i can't believe anyone would do that deliberately...there has to be some way to do it, or some way to re-enable it. off-by-default is merely annoying, but no big deal. off-forever would be inexcusable.
I cannot make sense of a line of perl at this time,
perl's really not that hard. if you have some basic scripting capability (or an ability to understand algorithms and flow control), and some passing familiarity with shell scripts or sed or awk, then perl is easy. it's nowhere near as difficult as some people like to make out. and learning some perl is at least as useful as learning sh and sed and awk put together. just ignore all the dickheads who say bullshit like "perl is write-only" or that it "looks like line-noise". they have no idea what they're talking about - at best, they're just scared of the sight of regexps as operators - beware the wild regexp, cage it in a function call or it'll get you.
but there are some folks I will trust, such as you and Russel Coker. I do not expect you to be perfect, but that you do know more than I, and from what I have seen, not malicious. I do try to comprehend even your examples first, but have to trust that you do know that much more in the subject of concern.
oh. I didn't mean me. you can trust anything i say, i'm perfect and never make a mistake. btw, i have a nice bridge i'd like to sell you cheap. craig -- craig sanders <cas@taz.net.au>
Hello cRAIG, On 8/30/20, Craig Sanders via luv-main <luv-main@luv.asn.au> wrote:
On Sun, Aug 30, 2020 at 05:24:39PM +1000, Mark Trickett wrote:
I did not choose Wayland, nor systemd, but that is now the Debian defaults. There are good reasons behind the changes, or at least I have seen some support that I will concur with on why Wayland over xwindows. However I do not find benefit in systemd,
most of my machines run systemd now. all but one, which just fails to boot at all if i try to boot it with systemd rather than sysvinit. I'm not entirely happy with that but i've given up fighting against it, i just don't have the energy for that.
I don't actually mind systemd as an init system, i.e. starting and stopping services - it's pretty good at that. it's all the other stuff (like ntp and dns and cron) that it tries to do that pisses me off, especially since it does such a shitty job of them.
I just disable as much of that systemd borg shit as I can and run the required services as extra daemons, like ntpd for ntp and unbound for dns resolution (I still use bind9 on a different IP address for serving my zones) and vixie cron.
the current install (Debian 10.5) is missing a piece of firmware, but I cannot read the message in time during boot, nor find it in the logs. I think it is for the network on the motherboard.
try something like 'journalctl -xe -b0', or 'dmesg | less'. You may be able to find the message you want by searching through that.
I tried looking through dmesg, but could not find any of the first screen before the splash screen and login. The original Unix design was well considered. I regard systemd as a Microsoftian Borg intrusion. There are other distros based on Debian that go back to the older init systems. I do not mind a slightly slower boot when it makes the system more stable and maintainable.
From my reading of pages found by a google search, there is a choice by the development team based on (in)security of casual copy and paste. I thought that it was likely a configuration issue, but cannot find. I tried a number of teminals, but not a lot, to find one that appears to be reasonable. I still need to do more research, when life leaves the time from the real world.
that would be kind of fucked up if they've disabled copy-paste into terminals or text editors entirely. so fucked up that that i can't believe anyone would do that deliberately...there has to be some way to do it, or some way to re-enable it.
off-by-default is merely annoying, but no big deal. off-forever would be inexcusable.
I think it may be possible to copy and paste between GUI editors and other windows, but not the terminal. As I said, there is a discussion that I found about the different text buffers, and security issues and how many and how they are implemented. It looks to me like they have thought about these issues, but not fully thought things through. They do have cogent arguments about security and the like, but again, I consider that they are still half assed. I would like both the sysV init and xwindows back, even if I have to make a change after the primary install. Making it this difficult is a black mark on the Debian development community. I can understand, and even sympathise that it is a lot of work, maybe too much, to keep the older stuff available, but I strongly disagree with the making it so unpleasantly difficult. That may partially be due to moving things in and out of the kernel, but it is also too much "feature creep" by the likes of systemd. As to Wayland, again I would like to see more of the discussion as to why to totally scrap the older xwindows.
I cannot make sense of a line of perl at this time,
perl's really not that hard. if you have some basic scripting capability (or an ability to understand algorithms and flow control), and some passing familiarity with shell scripts or sed or awk, then perl is easy.
it's nowhere near as difficult as some people like to make out. and learning some perl is at least as useful as learning sh and sed and awk put together.
just ignore all the dickheads who say bullshit like "perl is write-only" or that it "looks like line-noise". they have no idea what they're talking about - at best, they're just scared of the sight of regexps as operators - beware the wild regexp, cage it in a function call or it'll get you.
I want to learn, but meatspace is taking me away too much. I am now 65 and looking to working less, eventually. The people I do Traffic Control keep looking for more staff, but it is difficult. I have proven to be reasonably reliable while the younger ones come and go, some voluntarily, some just stupid and drugs. I have a bit of super, but not enough that I can sit back and scratch the itch to learn. I also need to keep practicing to maintain what I learn.
but there are some folks I will trust, such as you and Russel Coker. I do not expect you to be perfect, but that you do know more than I, and from what I have seen, not malicious. I do try to comprehend even your examples first, but have to trust that you do know that much more in the subject of concern.
oh. I didn't mean me. you can trust anything i say, i'm perfect and never make a mistake.
btw, i have a nice bridge i'd like to sell you cheap.
Again, anyone can make a mistake, some are a mistake.
craig
Regards, Mark Trickett
On Sunday, 30 August 2020 8:09:16 PM AEST Mark Trickett via luv-main wrote:
I tried looking through dmesg, but could not find any of the first screen before the splash screen and login. The original Unix design was well considered. I regard systemd as a Microsoftian Borg intrusion. There are other distros based on Debian that go back to the older init systems. I do not mind a slightly slower boot when it makes the system more stable and maintainable.
One feature of systemd is fast boot, unless it has an error and gets you 90 second timeouts etc. What I like are the better security features. One example is terminal control. If you have an init script that launches a daemon under a different UID then if that daemon isn't started by runuser or something similar then the daemon can push characters into the keyboard buffer of the shell. ps axo pid,sess,comm|grep $$ The above command shows processes in the same session group as your shell. Now you can modify all scripts to use runuser, but that's going to be a pain. systemd does all this for you. Also systemd allows blocking daemons from accessing /home and other security features. When it does those sorts of things they are in a standard format so you can grep service files to make sure that all daemons meet the security goals that you have instead of having to read lots of shell scripts written by different people for such things. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Sun, Aug 30, 2020 at 09:25:08PM +1000, Russell Coker wrote:
One feature of systemd is fast boot, unless it has an error and gets you 90 second timeouts etc.
It can be (and often is) worse than just 90 seconds. I've had both bootups and shutdowns delayed by 10s of minutes or longer while it retries and retries for progressively longer times. it's really fucking annoying. and you can't even hit Ctrl-C or something to force it to abort. A few times i've let systemd try to shutdown or reboot for HOURS, just out of curiousity to see if it will ever just give up on whatever's failing, and reboot anyway. AFAIK it would have gone on retrying forever if i hadn't power-cycled it. also, i don't reboot very often (on average, every two months or so. or even less often - e.g while my desktop machines got kernel upgrades about a week ago to 5.7.0-2-amd64 from debian sid, my main server/gateway box was last rebooted 201 days ago and is still running 5.3.0-3-amd64). saving a few seconds every year is hardly worth writing home about, and is more than offset by how long it takes to shutdown or reboot (IME that's *always* slower under systemd, usually by several minutes)
What I like are the better security features. One example is terminal control. If you have an init script that launches a daemon under a different UID then if that daemon isn't started by runuser or something similar then the daemon can push characters into the keyboard buffer of the shell.
and if you're running a daemon or something that does that, then you've got greater problems to worry about - anything that could install a compromised daemon already has root access and doesn't need access to your keyboard buffer. i'm not saying that this kind of separation is worthless, just that it's not enough by itself. To start with, don't install packages from untrusted repositories and NEVER use brawndo-installer, which is a favourite of idiot devs (usually python or ruby or nodejs devs, but not exclusively) and looks something like this: curl URL | sudo bash or as a function, highlighting all of its "features": brawndo() { curl $1 | sudo /usr/bin/env bash }
ps axo pid,sess,comm|grep $$
The above command shows processes in the same session group as your shell.
or you could use namespaces and lsns or pgrep --ns
Now you can modify all scripts to use runuser, but that's going to be a pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd devs didn't think or use themselves. or deliberately disallow. in that situation, you're fucked.
Also systemd allows blocking daemons from accessing /home and other security features.
no, the kernel does that. systemd just makes use of kernel namespace features. it's not alone in being able to do that - containerd and docker and firejail and many other programs make use of namespaces.
When it does those sorts of things they are in a standard format so you can grep service files to make sure that all daemons meet the security goals that you have instead of having to read lots of shell scripts written by different people for such things.
I really don't get why systemd fans are so terrified of shell scripts. especially when systemd is so poorly documented. it's not as if systemd unit files are paragons of clarity, or that there's any easy way to get an overview of the dependency relationship between units. craig -- craig sanders <cas@taz.net.au>
On Sunday, 30 August 2020 11:13:55 PM AEST Craig Sanders via luv-main wrote:
What I like are the better security features. One example is terminal control. If you have an init script that launches a daemon under a different UID then if that daemon isn't started by runuser or something similar then the daemon can push characters into the keyboard buffer of the shell.
and if you're running a daemon or something that does that, then you've got greater problems to worry about - anything that could install a compromised daemon already has root access and doesn't need access to your keyboard buffer.
If you have a daemon that is written and maintained by honourable people who have made a mistake in their coding (which happens to all programmers) then a compromised instance of the daemon could spawn a child process that waits for the sysadmin to restart the daemon and then escalates that to root compromise.
i'm not saying that this kind of separation is worthless, just that it's not enough by itself.
It's often not enough to be worth worrying about for one daemon when your whole system is like that. But having it work correctly for the entire system is nice.
To start with, don't install packages from untrusted repositories and NEVER use brawndo-installer, which is a favourite of idiot devs (usually python or ruby or nodejs devs, but not exclusively) and looks something like this:
curl URL | sudo bash
If you trust someone who's written the daemon then trusting their install script is no more risk.
Now you can modify all scripts to use runuser, but that's going to be a pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd devs didn't think or use themselves. or deliberately disallow. in that situation, you're fucked.
Which situations are you thinking of? The "kill processes in user session when they logout" was a good feature for some use cases and it was annoying that last time I checked the Debian systemd maintainers had disabled it instead of leaving it as a configuration option.
Also systemd allows blocking daemons from accessing /home and other security features.
no, the kernel does that. systemd just makes use of kernel namespace features. it's not alone in being able to do that - containerd and docker and firejail and many other programs make use of namespaces.
Yes, but systemd has a configuration option for it.
When it does those sorts of things they are in a standard format so you can grep service files to make sure that all daemons meet the security goals that you have instead of having to read lots of shell scripts written by different people for such things.
I really don't get why systemd fans are so terrified of shell scripts.
Because I've worked on so many shell scripts written by other people.
especially when systemd is so poorly documented. it's not as if systemd unit files are paragons of clarity, or that there's any easy way to get an overview of the dependency relationship between units.
"systemd-analyze critical-chain" is very handy. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Mon, Aug 31, 2020 at 01:22:32AM +1000, Russell Coker wrote:
curl URL | sudo bash
If you trust someone who's written the daemon then trusting their install script is no more risk.
part of my point is that anyone who suggests using brawndo-installer to install their code can not be trusted. they clearly fail the competence test.
Now you can modify all scripts to use runuser, but that's going to be a pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd devs didn't think or use themselves. or deliberately disallow. in that situation, you're fucked.
Which situations are you thinking of?
being able to manually change the exact order that particular daemons/services are loaded.
The "kill processes in user session when they logout" was a good feature for some use cases and it was annoying that last time I checked the Debian systemd maintainers had disabled it instead of leaving it as a configuration option.
actually it was a terrible anti-feature. one that has little reason to exist, and certainly should never be enabled by default. are the systemd devs completely ignorant of decades of normal *nix usage? they certainly act like it sometimes. anyone who needs or wants that kill-all-my-processes-when-i-logout functionality can do it in their .bash_logout (or equivalent for whatever shell they run). for everyone else, it's an extremely unpleasant surprise to find that the program they deliberately left running with nohup or screen or tmux or whatever was killed when they logged out. nobody expects their processes to be killed just because they logout. that's not how things are supposed to work.
Also systemd allows blocking daemons from accessing /home and other security features.
no, the kernel does that. systemd just makes use of kernel namespace features. it's not alone in being able to do that - containerd and docker and firejail and many other programs make use of namespaces.
Yes, but systemd has a configuration option for it.
so do other programs that make use of namespaces. systemd devs like to pretend that their baby is the only program capable of doing certain things, when that's not even remotely true. half the things they claim as wonderful features exclusive to systemd are re-implementations of ideas from other programs. and most of the rest are things that an init system has no business doing anyway.
I really don't get why systemd fans are so terrified of shell scripts.
Because I've worked on so many shell scripts written by other people.
So have I. I've also had to fix several broken unit files. It's possible to create shit with any tool. The reason i mention it is because "shell scripts are bad" is a common reason brought up to prove that systemd is great and why it's better than any other init. to me, cretinous statements like that say a lot more about the person saying it than about either systemd or shell scripts. or sysvinit. etc. Also, IME, shell scripts are easier to understand and fix when required. They're easier to modify, easier to temporarily enable/disable parts of them when testing stuff, easier to add diagnostic code, and more. lots of things are easier with shell scripts. They're not scary at all. sh scripting is a useful tool. systemd devs are doing everyone a great dis-service by teaching them that they're scary and difficult.
especially when systemd is so poorly documented. it's not as if systemd unit files are paragons of clarity, or that there's any easy way to get an overview of the dependency relationship between units.
"systemd-analyze critical-chain" is very handy.
that tells you what happened during the current boot session. it doesn't tell you what WILL happen during the next reboot. AFAIK there's no way of listing which unit files will be loaded, or in what order. e.g. definitive answers to questions like "will docker load before or after zfs.mount?", not just "maybe. reboot and find out". you can get that just by doing 'ls -l' of an /etc/rc[0-6].d/ directory. The Snn and Knn symlinks tell you the *exact* order that the scripts will run at boot or shutdown time, and you can override the default with insserv and the script's INIT INFO comments. BTW, i used that example (of zfs.mount and docker) for a reason. My main server runs docker configured to use zfs. Every reboot it's a gamble whether docker will start before or after zfs.mount. If it starts after, it works fine. That's what's supposed to happen. If it starts after zfs.mount, it breaks. and it creates and populates a fresh new /var/lib/docker directory, which prevents my zfs docker dataset from being mounted (I have to manually stop docker, and delete the directory before I can zfs mount /var/lib/docker and restart docker). this kind of shit is one of the reasons i'm reluctant to reboot my main server if i can possibly avoid it (and why i'd NEVER use systemd on a remote machine that I didn't have easy physical access to). There's always half a dozen or so little annoying things like this that I have to fix manually before the system is in its normal operating state. and finding out WHAT happened this time with systemd-analyze critical-chain doesn't tell me what will happen next time. and it doesn't tell me anything about WHY it happened or HOW to fix it permanently. craig -- craig sanders <cas@taz.net.au>
Mark Trickett via luv-main <luv-main@luv.asn.au> writes:
Many thanks for your excellent posts, I am learning more. However I have Debian 10, nominally up to date, and it has Wayland with Gnome as the desktop. I am finding it very frustrating that I cannot copy and paste to and from the XTerm window. I used to be able to do with earlier terminal emulation under the XWindows system. I used it to be able to copy text from a terminal into an email, and commands back from email, ensuring that I did not make typos. I do understand that there can be security issues if used without a measure of care and thoughtful, but it also has much merit when coping with some of the regular expressions that come up as examples in email and on web pages.
Are you sure this is a Wayland issue? There are a lot of issues that constantly trick me with copy and paste under X. e.g. * Clipboard vs primary. https://www.jwz.org/doc/x-cut-and-paste.html * Copy text. Close source application. Open destination text. Past text. Text is gone because closing source application killed copy buffer. * Some text applications can have mouse support and "steal mouse" and do their own thing. For example, in vim sometimes I have to use shift click to mark or paste text. But now I try to reproduce this on demand and I can't ... go figure. Google says the config value is "set mouse=a" * Probably others I can't think of right now. I don't know what happens with these under Wayland. But in short copy and paste is complicated. I have not used Wayland yet. But only because I have been lazy. But I note that there is now a i3 tiling manager in Debian testing that looks like it would be worth trying: https://swaywm.org/ https://github.com/swaywm/sway For a more complete list of window managers under Wayland see https://wiki.archlinux.org/index.php/Wayland#Tiling -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
Brian May <brian@linuxpenguins.xyz> writes:
* Some text applications can have mouse support and "steal mouse" and do their own thing. For example, in vim sometimes I have to use shift click to mark or paste text. But now I try to reproduce this on demand and I can't ... go figure. Google says the config value is "set mouse=a"
Oh, I found out why this is confusing me. Turns out if I ssh into a Debian account as root, by default I get mouse=a - so I have to use shift click everywhere, but with my own custom config I have mouse= -- Brian May <brian@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/
On Monday, 31 August 2020 8:14:57 AM AEST Brian May via luv-main wrote:
Brian May <brian@linuxpenguins.xyz> writes:
* Some text applications can have mouse support and "steal mouse" and do
their own thing. For example, in vim sometimes I have to use shift click to mark or paste text. But now I try to reproduce this on demand and I can't ... go figure. Google says the config value is "set mouse=a"
Oh, I found out why this is confusing me. Turns out if I ssh into a Debian account as root, by default I get mouse=a - so I have to use shift click everywhere, but with my own custom config I have mouse=
# cat /etc/vim/vimrc.local let g:skip_defaults_vim = 1 This is how I solved that problem. Presumably any more specific mouse settings could go into that file instead and will apply when logged in as root or any other user. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (6)
-
Andrew Pam -
Brian May -
Craig Sanders -
Mark Trickett -
Russell Coker -
Tim Connors