-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2017-12-01 at 06:32 +0300, Andrei Borzenkov wrote:

01.12.2017 02:09, Carlos E. R. пишет:

...

Hi,

This is a problem I hit on some computers only.

I "su -" from my normal user on a terminal under xfce. Then I try to start any graphical tool, and it fails:

~# xeyes Error: can't open display ~#

If I instead use "ssh -X root@localhost" it usually works.

This has happened to me on several computers along several years - but not all of them.

Ideas?

man 7 Xsecurity man pam_xauth

I never touch those things, specially pam, they are at defaults. Anyway: cer@Telcontar:~> man 7 Xsecurity No manual entry for Xsecurity in section 7 cer@Telcontar:~> cer@Telcontar:~> apropos xsecurity xsecurity: nothing appropriate. cer@Telcontar:~> - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlohZAwACgkQtTMYHG2NR9XJXACfaZGCFyTjkXqaRsiz3hnTUMCS s0kAnRsLbxnl2TTsCxVuQ7EY3A8MMcPL =T5uw -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2017-12-01 at 10:57 -0800, L A Walsh wrote:

Carlos E. R. wrote:

...

I "su -" from my normal user on a terminal under xfce. Then I try to start any graphical tool, and it fails:

~ # xeyes Error: can't open display

--- Is there a reason you used "su - xxx" instead of "su xxx" or "sudo xxx"?

I never use sudo. In my machine it only works for those commands I explictly allow. And "su -" because it is more similar to login, sets the home directory for instance. In this machine, it works fine. On some others, if fails with X. And only on some others.

su - clears most of your ENV vars. It doesn't clear TERM, but DISPLAY and REMOTEHOST weren't around when that decision was made. You'll need to reset your DISPLAY value to whatever it was before you did the "su - xxx" or just 'su xxx' or a properly configured sudo.

Ah, I'll try. [...] No, doesn't work, same error. Plain "su" does work, though.

...

~ #

If I instead use "ssh -X root@localhost" it usually works.

ssh came along after DISPLAY, so it's one that is passed -- especially when you use the -X".

Ah. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloh6FsACgkQtTMYHG2NR9XmzwCfYB/pI02e4TIW3J7bPzA90gp/ kCwAoImsTuB+gu9rgcB6yk1lHXMvGgbK =Ob9a -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-12-03 at 22:54 -0800, L A Walsh wrote:

Carlos E. R. wrote:

...

...

...

~ # xeyes Error: can't open display

---la walsh---: Is there a reason you used "su - xxx" instead of "su xxx" or "sudo xxx"?

I never use sudo. In my machine it only works for those commands I explictly allow.

---- To each their own. I include use of sudo in scripts so most of the script runs in user-mode, but some commands need to be run as root.

/If/ I'm using a command in a script I know that I'm going to use it often enough to warrant creating an entry in sudoers for that specific command.

...

And "su -" because it is more similar to login, sets the home directory for instance.

Right -- when you login on a terminal, by default, DISPLAY isn't set, only when you log in on a graphical terminal under X, will it usually be set.

...

In this machine, it works fine. On some others, if fails with X. And only on some others.

...

su - clears most of your ENV vars. It doesn't clear TERM, but DISPLAY and REMOTEHOST weren't around when that decision was made. You'll need to reset your DISPLAY value to whatever it was before you did the "su - xxx" or just 'su xxx' or a properly configured sudo.

Ah, I'll try. [...] No, doesn't work, same error. Plain "su" does work, though.

---- Um... now wait a poo -- I would expect it to work with plain 'su', as it shouldn't clear the ENV. But if you check the value of DISPLAY before and after your "su - user", you'll see it has been cleared. I suspect you forgot to re-EXPORT DISPLAY after you set it?

Ishtar:law> echo $DISPLAY athenae:0 Ishtar:law> su - law su: ignoring --preserve-environment, it's mutually exclusive with --login Password: law> echo $DISPLAY : 0 law> xlogo Error: Can't open display: :0 law> export DISPLAY=athenae:0 law> xlogo & law> #(no error)

But you see, I don't /do/ anything either in the machine where "su -" gets DISPLAY set nor on the machine when it doesn't.

Even my prompt changes with 'su -', as PAM no longer knows you are logging in from a remote system, so REMOTEHOST doesn't get set in my "/etc/security/pam_env.conf". I put my hostname in my prompt if my prompt setup detects I'm logging in remotely. Only when you 1st log in to your system can you see 'REMOTEHOST' (if there is one).

Thus pointing out the need for pam_env.conf only being called when you 1st log in to your system. There needs to be another "pam_session_env.conf" for reinitializing a session. I've seen some people mistakenly try to redefine 'pam_env' as being something that should be called/session -- which loses REMOTEHOST & a remote DISPLAY (as pam no longer knows the remote host -- which is only known on initial contact).

I'm completely lost with PAM. I'll have to wait till others find what is different or wrong regarding pam in my machines - and I never touch it, unless there is some report here that says "do, because...". The settings are default as far as I know. A nice howto for dummies would be nice to have. The machine where it works is older, and has been upgraded from SuSE 5.3, whereas the one where it doesn't has been freshly installed as leap 42.2. Similarly my laptop works, but has less upgrades and more recent. Another machine that had been freshly installed as 13.1. Others I don't remember. I think that on my virtual machines, all freshly installed, some work, some don't. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolGmcACgkQtTMYHG2NR9Ur7gCbBZtgslbi2wxnJ0cIYnAXvBwa 82EAn3o58lp1IYqTJqY6Oi5wOIZaF3Km =VhmL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-12-06 at 21:04 -0800, L A Walsh wrote:

Carlos E. R. wrote:

...

...

check the value of DISPLAY before and after your "su - user", ..maybe.. forgot to re-EXPORT DISPLAY after you set it?

But you see, I don't /do/ anything either in the machine where "su -" gets DISPLAY set nor on the machine when it doesn't.

---

There have been multiple changes to 'su' over the various releases, - even to the point of changing where it came from.

...

I'm completely lost with PAM. I'll have to wait till others find what is different or wrong regarding pam in my machines - and I never touch it, unless there is some report here that says "do, because...". The settings are default as far as I know.

---

How the pam functions are called is another area of frequent changes. Could you check a few files between the systems? Most likely cause would be differences in /etc/pam.d/common-session

See if they are the same or diff, and if diff, what are diffs?

My best guess would be a difference in whether or not 'pam_env.so' is included, less likely might be some difference in the content of "/etc/security/pam_env.conf".

...

I think that on my virtual machines, all freshly installed, some work, some don't.

The difference is in the package lxdm, it calls X differently than lightdm. I switched to the second, problem solved. You can see how we found that out in other posts of these thread, specially from Andrei LXDE is sadly lacking, I have found several problems with it. I tried the desktop first in my small server/multimedia-server, to have an small desktop, and I had to go back to XFCE, too many things missing or wrong, I forget which. Recently I found a bug. Before reporting I tried on factory, and the package was not in OSS. Yes, it had the same bug. Tried to report bug from the "report bug" link in the OBS, and bugzilla failed with unknown assignees. All that is in emails in this and the factory mail list. They told me that LXDE had been intentionally removed from factory for lack of maintenance or something. Now this other bug. I hope to remember not to try LXDE again. Too much time lost tracking weird issues. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlopHIAACgkQtTMYHG2NR9UmHQCfVLyossQ6xVdl1102xneArMU9 pvAAoIOfhLFr5KjjnSQtpMztLwXdC4BP =qlHV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-12-07 at 07:21 -0500, Anton Aylward wrote:

On 07/12/17 05:48 AM, Carlos E. R. wrote:

...

The difference is in the package lxdm, it calls X differently than lightdm. I switched to the second, problem solved. You can see how we found that out in other posts of these thread, specially from Andrei

Well, I don't have those two on my system, but I do have xdm and sddm (the latter gives me other problems but that's for another thread.)

As it happens, diff doesn't report any differences between them.

What is the case for you between /etc/pam.d/lxdm and /etc/pam.d/lightdm?

I no longer can compare, I deleted LXDE. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlopM70ACgkQtTMYHG2NR9VU6gCeOPkFnFS8/P/wMe0gBtN1AIfn KpUAn30B8mNeycTO8DdJKAlha0Oo2KFk =IQjn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-12-07 at 07:15 -0500, Anton Aylward wrote:

On 07/12/17 12:04 AM, L A Walsh wrote:

What Linda says makes me think it gets worse: don't expect two differer revisions (e.g.leap 42.2 vs 42.3, never mind 12.x) systems or two different revisions of th PAM subsystem to use exactly the same configuration files.

They certainly don't. I notice the changes on release upgrade. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlopMscACgkQtTMYHG2NR9XplwCgmHCSPX+HJmGciFtDRQvvWxI5 QyIAoJZc5RKw3YFeQLgsFwwsWjJO3PoF =QD5M -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/12/17 04:38 PM, L A Walsh wrote:

...

For example, I'm playing around at the moment with pam_mount  to try and defer so e of the boot time mounting be login time mounting.   

---

   Why?  why not just use the automounter?  If you use pam_mount, you'll need to make sure other ways to su/sudo/setuid to a different user would all be covered to mount what the userid "expects" to be there.  Sounds very fragile.

You are quite correct ... ... and completely missing the point. I said "I'm playing around with". Not something to the effect that "I'm putting into production". One plays with stuff to learn how it works. It's an easy and pretty inconsequential PAM module that I can experiment with, then I go on to play/experiment with the next one. There are a lot of question about PAM, where the line goes in the sequence, what required/optional means and more. You are right about the "expects to be there". And it's an opportunity to learn a bit more about XML. Learn, learn, learn. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/12/17 02:45, Basil Chupin wrote:

Welcome back, Linda

Welcome back, Linda ......  regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

L A Walsh wrote:

Email is much more like conversation than a book... When you are in a group and someone says something that you specifically answer, don't you usually look at them when talking to them?

But this is not email per se, it's a mailing list. Problem is if you start CCing the TO, quite a bunch of them will reply - only to you :( (Personally, I don't appreciate additional CC in a list too much. I sort list mails in a separate folder using procmail, so I don't get distracted by related mails in my inbox. You see, you can't always please everyone...) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 10:21 +0100, Richard Brown wrote:

On 4 December 2017 at 10:09, pit <> wrote:

...

L A Walsh wrote:

...

Email is much more like conversation than a book... When you are in a group and someone says something that you specifically answer, don't you usually look at them when talking to them?

But this is not email per se, it's a mailing list. Problem is if you start CCing the TO, quite a bunch of them will reply - only to you :(

(Personally, I don't appreciate additional CC in a list too much. I sort list mails in a separate folder using procmail, so I don't get distracted by related mails in my inbox. You see, you can't always please everyone...)

If you use procmail, you can filter those directed copies elsewhere and not see them: # List Mail only :0f * ^X-Mailinglist: opensuse | $FORMAIL -bfi 'Reply-To: "OS-en" <opensuse@opensuse.org>' :0 aw: $HOME/Mail/.D-locks/_Lists/os-en.lock | $DELIVER -m _Lists/os-en # Duplicated posts: :0 w: $HOME/Mail/.D-locks/_Lists/in_dups.lock * ^TO_((suse-linux-s|suse-linux-e|suse-security|suse-programming-e)@suse.com|(opensuse-offtopic|opensuse-es|opensuse-programming|opensuse-project|opensuse-security|opensuse-translation|opensuse-translation-es|opensuse-factory|opensuse)@opensuse.org) | $DELIVER -m _Lists/in_dups (Mutandis mutandi)

That is why the openSUSE Mailing list rules are written the way they are:

https://en.opensuse.org/openSUSE:Mailing_list_netiquette#Personal_and_mail_l...

"If the user has sent the reply to you and to the list, then respond to *only* the list unless the poster *specifically* requests personal mail."

I guess we can consider the creation of this thread as an indication that Linda always specifically requests personal mail when she is addressing, in addition to list mail.

I, like Linda, also quite like being mailed directly when a mailinglist thread is addressing me.

But our guidance is written in a way that these lists should be comfortable for those who feel differently also.

Ok, then, but in that case I would ask those people to specifically say this in all their posts, in one line in signature or salutation - because I will not be able to remember which are the people that want a CC ;-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolFrQACgkQtTMYHG2NR9XhLgCgkR7p4ibAehV802eSqe8MIf/8 U2cAnj86XrHMLpD12Brxi+pLbBPJGta5 =YmjR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 11:38 -0000, Dave Howorth wrote:

On Mon, 4 Dec 2017 10:34:36 +0100 (CET) "Carlos E. R." <> wrote:

...

If you use procmail, you can filter those directed copies elsewhere and not see them:

# List Mail only :0f * ^X-Mailinglist: opensuse | $FORMAIL -bfi 'Reply-To: "OS-en" <opensuse@opensuse.org>' :0 aw: $HOME/Mail/.D-locks/_Lists/os-en.lock | $DELIVER -m _Lists/os-en

# Duplicated posts: :0 w: $HOME/Mail/.D-locks/_Lists/in_dups.lock * ^TO_((suse-linux-s|suse-linux-e|suse-security|suse-programming-e)@suse.com|(opensuse-offtopic|opensuse-es|opensuse-programming|opensuse-project|opensuse-security|opensuse-translation|opensuse-translation-es|opensuse-factory|opensuse)@opensuse.org) | $DELIVER -m _Lists/in_dups

(Mutandis mutandi)

...

...

Ok, then, but in that case I would ask those people to specifically say this in all their posts, in one line in signature or salutation - because I will not be able to remember which are the people that want a CC ;-)

Fortunately, there is a better way. (i.e. one that might work :) If somebody wants a personal reply sent, as well as the copy to the list, then they should set a reply-to header indicating that. Then the MUA of whoever is replying will take care of the request.

Will not work, see my procmail rule. I overwrite the reply-to header. And if it works, will cause me swearing quietly and edit the To: header manually back to the list only. :-P - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolNiUACgkQtTMYHG2NR9ViFACeJVxJ4aegf/pZsiVl8NDocy5J 7gEAnicUd1PBwh98fiqB11tBlzI/tpiF =hQri -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Dec 4, 2017 at 1:27 AM, L A Walsh <suse@tlinx.org> wrote:

Thanks... Now if I could only get people to Cc the person they are addressing, I would see these soon after they were sent vs. some time later...when they go to group, they get filed in my opensuse group folder vs. when addressed to me, they go to the "addressed_to_me" folder which gets about 5x more often.

You have any idea how many times I've done the reply to original sender and list by accident and gotten flack for that? Can never win. It gets more complicated tho. The message I am replying to had you, ellanios82 & Basil for the reply, so I have to decide whether to: 1. Just reply to list, which is what I did. 2. Reply to list and just you 3. Reply to all If I reply to all, but it's only addressed to you, they may wonder why I replied to it. It's like people who don't edit the quoted message. Not all of us have unlimited data plans, so pulling the same thing several times can eat that up over a month. Also, when bottom posting, it makes the message length really long. The reason I use gmail for mailing lists is it defaults to conversation view, which keeps threads together. Of course, then some replies add stuff like "re:" in front of the subject and they get out of whack that way. I've got almost 40k unread subjects.......... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Dec 4, 2017 at 12:56 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:

Gmail is broken for mail lists. I use Thunderbird and it correctly display all those "Re" in the same conversation, because "sorting by conversation" which is in other clients call "sorting by thread" is not done on the subject line. It is done on other headers: Message-ID, In-Reply-To, and References.

I haven't used a mail client in almost 20 years when I got broadband. I've been reading email online since. A mail client made sense to me when I needed to minimize telephone usage. After that it didn't matter. Plus, the mail client programmers change the interface at least as much as the webmail programmers. Further, I'm on several machines usually and having a mail client on each would be confusing. gmail works for me even with it's warts. But I only use it for mailing lists anyway.

Besides that, Gmail also removes the copy sent to you from the mail list. Suppose this post goes to you and to the mail list: you will only get the one sent to you; the copy sent to the mail list will take long to arrive at Gmail, and Gmail will delete it. Similarly, when you post or reply to the list you will never see the post from the list sent to you, because Gmail deletes it as a duplicate of the one in your sent folder.

I've noticed that, but I haven't seen any issue with mail not getting out. So far. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos, et al -- ...and then Carlos E. R. said... % ... % Gmail is broken for mail lists. [snip] That "for mail lists" part is redundant ;-) Happy Holidays :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.1712082238011.25806@Telcontar.valinor> On Friday, 2017-12-08 at 07:23 -0800, Linda Walsh wrote:

Date: Fri, 08 Dec 2017 07:23:01 -0800 From: Linda Walsh <...@tlinx.org> Reply-To: OS-en <...@opensuse.org> To: Larry Stotler <...@gmail.com> Cc: SuSE Linux <...@opensuse.org> Subject: [opensuse] Re: addressing email to poster if talking to poster.

I hit reply to all on this post, as asked, but only the addresses for the list and Larry were filled, not the one to Linda. I tried twice. Go figure. Ah, yes, there is a "reply-to" active. I'll leave only the list address, as per list netiquette.

Larry Stotler wrote:

...

On Mon, Dec 4, 2017 at 1:27 AM, L A Walsh <suse@tlinx.org> wrote:

It's far easier to delete an extra copy than to generate a copy of an email you don't know about *OR*, never received. I've seen multiple instances where list-email gets rejected for some reason or another, but personal mail goes through. I receive notices from the suse list manager that some list messages didn't go through. If they were replies to me, I won't know what I missed unless it was also sent directly to me.

You can find out what was lost and/or tell the list server to send it again. In my case, all those cases are spam, or at least posts my ISP thinks are spam.

linda

p.s. -- I used to never speak up about this issue until I realized that those who get extra copies almost always speak up and have been getting lists to adopt their views. It's a matter of them being too lazy to delete an extra copy or set their filters to delete duplicates, vs. the affect on those who, for whatever reason, don't get ANY copy when only a list-copy is sent.

If you send a copy to all, when the recipient is on gmail, he will not receive the copy from the mail list. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlorB8UACgkQtTMYHG2NR9XoqQCfTn42ZdEKpYi1xkvRqmZl1ljh cEcAoIxP6UBbimKPY9oxMzKf7M89Gf5B =ieLL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Larry Stotler <larrystotler@gmail.com> [12-08-17 20:34]:

On Fri, Dec 8, 2017 at 10:23 AM, Linda Walsh <suse@tlinx.org> wrote:

...

I can imagine since most people have no idea about the RFC standards nor care when messages and replies don't go through -- until they _don't_ get something (which they, *usually*, don't notice).

Well, I personally don't know the RFC standards on a great many things.

...

...

2. Reply to list and just you Reply to list and "just" me? Do you mean "reply to just me", or reply to the list AND me?

List & you. I usually discourage off list mails since the idea is to continue the discussion on the list, unless specifically asked or informed that the reply is off list.

then reply should be "to the list". that is where the conversation is, unless _specifically_ requested otherwise. trimmeddddd..... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2017-12-02 at 13:13 -0000, pit wrote:

Carlos E. R. wrote:

...

...

Ideas?

cat /etc/pamd/su auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so

Guess the last line is missing on the hosts where it doesn't work?

Isengard:~ # cat /etc/pam.d/su #%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so Isengard:~ # No... :-( And the one that works has the same. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloj/p4ACgkQtTMYHG2NR9UYTgCgmRPvv0SJSX6m2K/vVoUZBjb7 sREAoIoykPU+hTYrzrkWJ69C+iGpfWMu =/nOK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-12-03 at 16:56 +0300, Andrei Borzenkov wrote:

03.12.2017 16:39, Carlos E. R. пишет:

...

On Saturday, 2017-12-02 at 13:13 -0000, pit wrote:

"su -" is using su-l PAM service.

Ah, thanks. Not working: Isengard:~ # cat /etc/pam.d/su-l #%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so Isengard:~ # Working: cer@Telcontar:~> cat /etc/pam.d/su-l #%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so cer@Telcontar:~> I don't see (visually) any difference :-? - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlokA3wACgkQtTMYHG2NR9U4LACeNkYtyp/eK7ld0UJCHEHB+495 79oAn3jXMEl4AoOf28DDgOgwHzhRetsO =f7Dp -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-12-03 at 15:47 -0000, pit wrote:

Carlos E. R. wrote:

...

I don't see (visually) any difference :-?

Well, then go back to his first suggestion: man pam_xauth :D

In detail, try putting the 'debug' option in /etc/pam.d/su-l:

session optional pam_xauth.so debug

I could try that...

and check the syslog. Does any of the user/root directories involved have a ~/.xauth directory? From the manpage:

pam_xauth will only forward keys if xauth can list a key connected to the $DISPLAY environment variable.

Primitive access control is provided by ~/.xauth/export in the invoking user's home directory and ~/.xauth/import in the target user's home directory.

If a user has a ~/.xauth/import file, the user will only receive cookies from users listed in the file. If there is no ~/.xauth/import file, the user will accept cookies from any other user.

In the computer that works, there is no ~/.xauth/ directory. Same in the computer that does not work. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlokXWUACgkQtTMYHG2NR9V7fQCeOpsSeB8M3Ad1O1lUuPFFva03 wt8An3luZK5VLZAI4QbRgJKpJKUa2BS9 =cplz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2017-12-03 at 19:19 +0300, Andrei Borzenkov wrote:

03.12.2017 17:00, Carlos E. R. пишет:

...

On Sunday, 2017-12-03 at 16:56 +0300, Andrei Borzenkov wrote:

...

03.12.2017 16:39, Carlos E. R. пишет:

...

On Saturday, 2017-12-02 at 13:13 -0000, pit wrote:

...

"su -" is using su-l PAM service.

Ah, thanks.

Not working:

Isengard:~ # cat /etc/pam.d/su-l #%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so Isengard:~ #

Working:

cer@Telcontar:~> cat /etc/pam.d/su-l #%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so cer@Telcontar:~>

I don't see (visually) any difference :-?

Well, add "debug" parameter to pam_xauth.so to see what it does in each case. You original (truncated) error message imply $DISPLAY is empty and in normal case pam_xauth is the only module that forwards it.

Yes, DISPLAY is empty in the machine that works. I did not paste output from that machine into the mail list because that machine doesn't have email configured, it has its own keyboard, I was trying locally on it. Thus I hand copied the error message. Writing the debug option now. [...] This is the log section: <10.3> 2017-12-03T21:28:25.068246+01:00 Isengard su - - - The gnome keyring socket is not owned with the same credentials as the user login: /run/user/1000/keyring/control <10.3> 2017-12-03T21:28:25.068801+01:00 Isengard su - - - gkr-pam: couldn't unlock the login keyring. <4.5> 2017-12-03T21:28:25.085723+01:00 Isengard su - - - (to root) cer on pts/12 <10.6> 2017-12-03T21:28:25.086657+01:00 Isengard su - - - pam_unix(su-l:session): session opened for user root by (uid=1000) <10.7> 2017-12-03T21:28:25.089408+01:00 Isengard su - - - pam_systemd(su-l:session): Cannot create session: Already running in a session <10.7> 2017-12-03T21:28:25.089928+01:00 Isengard su - - - pam_xauth(su-l:session): requesting user 1000/100, target user 0/0 <10.7> 2017-12-03T21:28:25.092222+01:00 Isengard su - - - pam_xauth(su-l:session): /home/cer/.xauth/export does not exist, ignoring <10.7> 2017-12-03T21:28:25.092723+01:00 Isengard su - - - pam_xauth(su-l:session): /root/.xauth/import does not exist, ignoring <10.7> 2017-12-03T21:28:25.093107+01:00 Isengard su - - - pam_xauth(su-l:session): reading keys from `/home/cer/.Xauthority' <10.7> 2017-12-03T21:28:25.093395+01:00 Isengard su - - - pam_xauth(su-l:session): running "/usr/bin/xauth -f /home/cer/.Xauthority nlist :0.0" as 1000/100 <10.7> 2017-12-03T21:28:25.094920+01:00 Isengard su - - - pam_xauth(su-l:session): no key I'll now try on the machine that does work: <10.3> 2017-12-03 21:30:35 Telcontar su - - - The gnome keyring socket is not owned with the same credentials as the user login: /run/user/1000/keyring/control <10.3> 2017-12-03 21:30:35 Telcontar su - - - gkr-pam: couldn't unlock the login keyring. <4.5> 2017-12-03 21:30:35 Telcontar su - - - (to root) cer on pts/37 <10.6> 2017-12-03 21:30:35 Telcontar su - - - pam_unix(su-l:session): session opened for user root by (uid=1000) <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_systemd(su-l:session): Cannot create session: Already running in a session <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): requesting user 1000/100, target user 0/0 <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): /home/cer/.xauth/export does not exist, ignoring <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): /root/.xauth/import does not exist, ignoring <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): reading keys from `/home/cer/.Xauthority' <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): running "/usr/bin/xauth -f /home/cer/.Xauthority nlist :0.0" as 1000/100 <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): writing key `0100 0009 54656c636f6e746172 0001 30 0012 4d49542d4d414749432d434f4f4b49452d31 0010 49ca804d6fcdeb415f7c48dfe678ebfc#012' to temporary file `/root/.xauthHPgge6' <10.7> 2017-12-03 21:30:35 Telcontar su - - - pam_xauth(su-l:session): running "/usr/bin/xauth -f /root/.xauthHPgge6 nmerge -" as 0/0 cer@Isengard:~> l .Xauthority - -rw------- 1 cer users 206 Dec 3 21:23 .Xauthority cer@Isengard:~> cer@Telcontar:~> l .Xauthority - -rw------- 1 cer users 898 Nov 15 02:37 .Xauthority cer@Telcontar:~> I see that on Telcontar a ky is written, and on Isengard it isn't (says "no key"). Then it runs xauth again on Telcontar (the one that works) But I have no idea how to interpret the log, though. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlokYN4ACgkQtTMYHG2NR9VA0ACfW+08PaEziQ1GKL7vHTeuMG7s DaoAnA9R4SX6c89bAD+ligdeIIdvLlTv =zk5b -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 06:24 +0300, Andrei Borzenkov wrote:

03.12.2017 23:38, Carlos E. R. пишет:

...

<10.7> 2017-12-03T21:28:25.093395+01:00 Isengard su - - - pam_xauth(su-l:session): running "/usr/bin/xauth -f /home/cer/.Xauthority nlist :0.0" as 1000/100 <10.7> 2017-12-03T21:28:25.094920+01:00 Isengard su - - - pam_xauth(su-l:session): no key

...

...

cer@Isengard:~> l .Xauthority -rw------- 1 cer users 206 Dec 3 21:23 .Xauthority cer@Isengard:~>

what

echo $DISPLAY

empty

xauth list

say here?

Isengard:~ # cat p Isengard/unix:16 MIT-MAGIC-COOKIE-1 6028e808083df347485be0017d5ed244 Isengard/unix:17 MIT-MAGIC-COOKIE-1 4b4c547ea3bc186f7a0cdf0e22559d3d Isengard/unix:14 MIT-MAGIC-COOKIE-1 dabb5afa723277cc3431923b0f8fe39a Isengard/unix:11 MIT-MAGIC-COOKIE-1 0faa05f1092b346671b0a60971279e0a Isengard/unix:12 MIT-MAGIC-COOKIE-1 ff4a728282551684174a6e87ea761625 Isengard:~ # (I did echo $DISPLAY > p xauth list >> p to get it - there is no email on that machine) Whereas on telcontar I get: Telcontar:~ # echo $DISPLAY :0.0 Telcontar:~ # xauth list Telcontar/unix:0 MIT-MAGIC-COOKIE-1 49ca804d6fcdeb415f7c48dfe678ebfc Telcontar:~ # - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlokyLgACgkQtTMYHG2NR9VfCgCeJi2hr7QjcpHR24iiTSOzDCbX MKwAn3y3zjg9pqRYNWY5aH+lIwXIBncn =kfO6 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 07:10 +0300, Andrei Borzenkov wrote:

04.12.2017 07:01, Carlos E. R. пишет:

...

On Monday, 2017-12-04 at 06:24 +0300, Andrei Borzenkov wrote:

...

03.12.2017 23:38, Carlos E. R. пишет:

...

<10.7> 2017-12-03T21:28:25.093395+01:00 Isengard su - - - pam_xauth(su-l:session): running "/usr/bin/xauth -f /home/cer/.Xauthority nlist :0.0" as 1000/100 <10.7> 2017-12-03T21:28:25.094920+01:00 Isengard su - - - pam_xauth(su-l:session): no key

...

...

cer@Isengard:~> l .Xauthority -rw------- 1 cer users 206 Dec 3 21:23 .Xauthority cer@Isengard:~>

...

what

...

echo $DISPLAY

Sorry? You are doing it in X11 session, are not you?

Yes, of course. All that is X11, local, not ssh. Misunderstanding? DISPLAY is set on Isengard as user, but not when I "su -" to root. As user it contains ":0.0" The issue is precisely that DISPLAY is cleared when doing "su -" on that machine (Isengard), but it is not in Telcontar. And I'm copying by hand the results in Isengard because mouse copy-paste does not work: there is no third button in the mouse, and simultaneously clicking Btn1&2 is ignored. So I have to hand copy somethings. I say 'it contains ":0.0"' instead of pasting the command complete with results as would be my wont. HTH. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEUEARECAAYFAlolHLAACgkQtTMYHG2NR9XpiQCYzJZzwYPk6UwOOIxvPt4Y3eeN WgCdGOrmPB3dyEBFKMMQm3c2Dv+xgSk= =Xz/j -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 13:02 +0300, Andrei Borzenkov wrote:

On Mon, Dec 4, 2017 at 1:00 PM, Carlos E. R. <> wrote:

...

On Monday, 2017-12-04 at 07:10 +0300, Andrei Borzenkov wrote:

...

...

Sorry? You are doing it in X11 session, are not you?

Yes, of course. All that is X11, local, not ssh.

Misunderstanding?

DISPLAY is set on Isengard as user, but not when I "su -" to root.

I asked you to do it as normal user before su; we already know that su does not forward DISPLAY and cookie, now we need to see the original state.

Sorry, then I misunderstood. cer@Isengard:~> echo $DISPLAY :0.0 cer@Isengard:~> xauth list #00fc##: MIT-MAGIC-COOKIE-1 2f8603a4d9d474bee64559de421386a6 Isengard/unix:12 MIT-MAGIC-COOKIE-1 cdc43b385cb100f5a025a0179ef79605 Isengard/unix:13 MIT-MAGIC-COOKIE-1 75260829662bac2cd23066e3e1852ae0 Isengard/unix:10 MIT-MAGIC-COOKIE-1 22f22f2f4490b4c0c07b9897581c31f0 cer@Isengard:~> su - Password: Isengard:~ # echo $DISPLAY Isengard:~ # xauth list Isengard/unix:16 MIT-MAGIC-COOKIE-1 6028e808083df347485be0017d5ed244 Isengard/unix:17 MIT-MAGIC-COOKIE-1 4b4c547ea3bc186f7a0cdf0e22559d3d Isengard/unix:14 MIT-MAGIC-COOKIE-1 dabb5afa723277cc3431923b0f8fe39a Isengard/unix:11 MIT-MAGIC-COOKIE-1 0faa05f1092b346671b0a60971279e0a Isengard/unix:12 MIT-MAGIC-COOKIE-1 ff4a728282551684174a6e87ea761625 Isengard:~ # p.txt lines 1-18/18 (END) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolIDgACgkQtTMYHG2NR9WhmgCfazBzTLie9mypjvcXe5ZcUhUr kKQAn3XpXWrwZMIqe8YjIoVsZb7Qrf0N =yfV4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 13:25 +0300, Andrei Borzenkov wrote:

On Mon, Dec 4, 2017 at 1:15 PM, Carlos E. R. <> wrote:

...

Sorry, then I misunderstood.

cer@Isengard:~> echo $DISPLAY :0.0 cer@Isengard:~> xauth list #00fc##: MIT-MAGIC-COOKIE-1 2f8603a4d9d474bee64559de421386a6 Isengard/unix:12 MIT-MAGIC-COOKIE-1 cdc43b385cb100f5a025a0179ef79605 Isengard/unix:13 MIT-MAGIC-COOKIE-1 75260829662bac2cd23066e3e1852ae0 Isengard/unix:10 MIT-MAGIC-COOKIE-1 22f22f2f4490b4c0c07b9897581c31f0

There is no cookie for your DISPLAY which explains failure to forward it. Please show X command line:

ps -efwww | grep X

cer@Isengard:~> ps -efwww | grep X root 2531 2524 2 Nov08 tty7 16:34:55 /usr/bin/X :0 vt07 -nolisten tcp cer 4332 2524 0 Nov08 ? 00:00:00 /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc cer 4393 1 0 Nov08 ? 00:00:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/cer/.gnupg/agent.info-Isengard:0 /etc/X11/xinit/xinitrc cer 4395 4332 0 Nov08 ? 00:00:09 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/cer/.gnupg/agent.info-Isengard:0 /etc/X11/xinit/xinitrc cer 4396 4332 0 Nov08 ? 00:01:22 /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/cer/.gnupg/agent.info-Isengard:0 /etc/X11/xinit/xinitrc cer 30480 29165 0 11:56 pts/15 00:00:00 grep --color=auto X cer@Isengard:~> On the machine that works, for comparison: cer@Telcontar:~> ps -efwww | grep X root 4256 4251 0 Nov08 tty7 04:50:06 /usr/bin/X :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch cer 4488 4347 0 Nov08 ? 00:00:00 /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc cer 7583 5771 0 Nov11 pts/44 00:00:19 /usr/bin/mc -P /tmp/mc-cer/mc.pwd.5771 . /home/cer/Varia/Gadgetos/MovilMotorolaPlayX/Whatsup.join cer 9937 22457 0 11:12 pts/63 00:00:00 ssh -X cer@Isengard.valinor cer 12172 4990 0 11:57 pts/24 00:00:00 grep --color=auto X cer 15024 10532 0 Dec03 pts/61 00:00:00 ssh -X root@Isengard.valinor cer@Telcontar:~> Telcontar uses "/usr/sbin/lightdm" Isengard uses "/usr/bin/lxdm -d" - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolLPoACgkQtTMYHG2NR9VMmgCgmVyDKnvgPmbcAKn0pWVYdmD7 hTEAn07kDPWYncmV0ggQnnNTBH0FfkRQ =ELBM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Dec 4, 2017 at 2:09 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:

cer@Isengard:~> ps -efwww | grep X root 2531 2524 2 Nov08 tty7 16:34:55 /usr/bin/X :0 vt07 -nolisten tcp

Did you try to simply su - export DISPLAY=:0 xeyes ?? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

04.12.2017 14:44, Carlos E. R. пишет:

But what I understand now is that "lxdm" sets it right, that I should change to "lightdm", and if that works on Isengard, report a bug against lxdm and maybe forget it all.

Well, lxdm has code to pass -xauth flag since two years, probably in 0.5.2. lxdm in Leap 42.3 is 0.4.1, which is 6 years old. I suspect this exceeds scope of simple bug report and quite unlikely will be fixed for Leap 42, especially seeing that lxdm is not present in factory ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 21:12 +0300, Andrei Borzenkov wrote:

04.12.2017 14:44, Carlos E. R. пишет:

...

But what I understand now is that "lxdm" sets it right, that I should change to "lightdm", and if that works on Isengard, report a bug against lxdm and maybe forget it all.

Well, lxdm has code to pass -xauth flag since two years, probably in 0.5.2. lxdm in Leap 42.3 is 0.4.1, which is 6 years old. I suspect this exceeds scope of simple bug report and quite unlikely will be fixed for Leap 42, especially seeing that lxdm is not present in factory ...

Well, I switched that machine to lightdm (I had to install it) and things work, so I'm happy :-) Thank you! (now I'm uninstalling LXDE, to save space, and not to get tricket easily into found problems) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlolwb0ACgkQtTMYHG2NR9WRUQCgiqemBH+1CT4cotqZ0T33zx42 zhcAnRY1aXvtiB1Tz1QnNK9VIMfREiZR =UNi7 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-12-04 at 13:58 +0100, David Haller wrote:

On Mon, 04 Dec 2017, Andrei Borzenkov wrote:

...

On Mon, Dec 4, 2017 at 2:09 PM, Carlos E. R. <t> wrote:

...

...

cer@Isengard:~> ps -efwww | grep X root 2531 2524 2 Nov08 tty7 16:34:55 /usr/bin/X :0 vt07 -nolisten tcp

Did you try to simply

su - export DISPLAY=:0 xeyes

My normal user is "dh". Then I just do that:

# ln -sf /home/dh/.Xauthority /root/.Xauthority

...

HTH, -dnh

I think I will just switch to "lightdm". LXDE things are plagued with problems and not much maintained in openSUSE.

PS: my prompt is:

root@grusum[12]: ~ (0)# ^^^^ ^^^^^^ ^^ | | ` '#' for root, '$' for users | | | | `- last exit status (preserving "$?"[1]) user host | `- cwd `- tty/pts

It also sets the xterm title via the \007 escape (without the exit-status and the prompt).

[1] as in dh@grusum[5]: ~ (0)$ false dh@grusum[5]: ~ (1)$ echo $? 1 dh@grusum[5]: ~ (0)$ false; echo $?; 1 dh@grusum[5]: ~ (0)$

Why? What interest is knowing the tty/pts? :-? - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlollXAACgkQtTMYHG2NR9WGMwCcDrk7dhCd+0pe2ceyJss0f0S/ 3+sAn0PFh41DUXAiVmExdMY/W7xxAmL8 =kg6+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David Haller wrote:

Prof:    So the American government went to IBM to come up with a data encryption standard and they came up with ... Student: EBCDIC!                     -- snarfed off of Ralph Angenendt

Hahaha, good one! -- Per Jessen, Zürich (0.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Wed, 06 Dec 2017, Carlos E. R. wrote:

On Wednesday, 2017-12-06 at 09:00 +0100, David Haller wrote:

...

On Mon, 04 Dec 2017, Carlos E. R. wrote:

...

On Monday, 2017-12-04 at 13:58 +0100, David Haller wrote:

...

PS: my prompt is:

root@grusum[12]: ~ (0)# ^^^^ ^^^^^^ ^^ | | ` '#' for root, '$' for users | | | | `- last exit status (preserving "$?"[1]) user host | `- cwd `- tty/pts

Why? What interest is knowing the tty/pts? :-?

I start 8 xterms after logging in, with specified geometries and usually they're used for specific stuff. E.g. there's big main one where I do most work, and a few quite small ones for stuff like where I don't need to see much output, such as downloads.

Me too, but I differentiate them by their position, tittle, and workspace.

That too. But if I'm running stuff in multiple terms (say, 4 wget's) in those four small ttys, and want to do something about that, and use: $ dh@grusum[3]: ~ (0)$ ps a | grep pts/3 2805 pts/3 Ss 0:02 bash 30963 pts/3 R+ 0:00 ps a 30964 pts/3 D+ 0:00 grep pts/3 to find _THAT_ one wget/make/gcc/whatever in that one term that e.g. got stuck or whatnot, based on the tty-no in the relevant prompt _and_ window-title, while the command has long since scrolled out of the view ;) Ctrl-z ; ps a | grep pts/${TTY}; kill -9 PID ... ;) When both killall and pidof would be of no use... $ pidof xterm 3458 3337 3079 3029 2984 2940 2866 2796 2763 2755 2657 $ pgrep xterm | xargs 2657 2755 2763 2796 2866 2940 2984 3029 3079 3337 3458 But then again, you usually don't want to kill neither the bash nor the xterm, but rather the process running "under" it. As I don't have wget's or some such running, I'll use two mplayers as a "placeholder" processes: $ pidof mplayer 8484 7071 $ pgrep mplayer | xargs 7071 8484 $ pgrep -t pts/1 | xargs 2758 8484 $ pgrep -t pts/7 | xargs 3047 3983 7071 Still useless. $ ps ax | grep [p]ts/7.*mpla 7071 pts/7 SL+ 0:00 /usr/bin/mplayer foo.mp4 $ ps ax | grep [p]ts/1.*mpla 8484 pts/1 SL+ 8:23 /usr/bin/mplayer bar.mkv $ So just by the info program+tty I get a useful output. Refined to $ ps ax -eo pid,tty,cmd | awk '$2 == "pts/N" && $3 ~ /mpla/ { print $1;}' I can get at the PIDs in a safe way (depending on the regex against which the commandline in $3 is matched) and could feed them to kill...

...

The tty/pts also shows up in the window title (which is often dynamically updated by running commands, but the prompt, including the pts, is kept), which helps to discern those 8+ xterm I have open in the window list. Compare the use of a window list of

dh@grusum: ~ dh@grusum: ~ dh@grusum: ~ [..] vs.

dh@grusum[1]: ~ dh@grusum[2]: ~ dh@grusum[3]: ~ [..] How do you get the window list like that? A command produces it?

Manual & copy & paste ;) Or do you mean how do I get the window-titles to reflect that? That's all in the PS1 magic: ==== ~/.bashrc ==== ### DO NOT 'export' TTY! ### TTY="$(tty)" TTY="${TTY##*[\/a-zA-Z]}" # set prompt PS1="\[\033[1;37;44m\]\u@\h[ \[\010${TTY}\]]:\[\033[0m\] \w ( \[\010\$?\])\$\[\033[0m\] " # set window title in xterm, reset to basic prompt in emacs case $TERM in xterm*) PS1="\[\033]0;\u@\h[${TTY}]: \w\007\]${PS1}" ;; *emacs*) PS1='\u@\h: \w $ ' ;; esac ==== It's not perfect, but works most of the time quite beautifully. Biggest problem is when the prompt is too long to fit in one line, bash/xterm get's confused despite using the \[..\] to mark "zero-width" stuff... Using Ctrl-l helps a bit. Oh, and I tweak colors depending on host/chroot/role.

...

And as I start those 8 via a script, I "know" that "[2]" is my main one at 103x44, and 3-6 are the small 81x10 terms...

I change the tittle in the script :-)

I "change" it with every command :P See the "magic" (see below) ESC ] 0 ; ${WHATEVER} \007 escape in my PS1 (for the case of an xterm). Oh, and BTW: even if other commands (like mc) do change the title in between, it gets reset on exiting / the next command... E.g. the xterm _window title_ dh@grusum[13]: ~ changes to mc [dh@grusum]: ~ once I call mc (Hm, I should tell mc to include the tty, but anyway, the mc-prompt at the bottom _does_ display a tty, in this example it's dh@grusum[ 14]: ~ ( 0)$ (note the ignored '\010' (backspace) escapes and the increased tty-no)[1] And when I exit mc again, the window title changes back to dh@grusum[13]: ~ And depending on mc-config/mc-wrapper.sh, if you end-up elsewhere on exit, it does change to e.g. dh@grusum[13]: /tmp/ on exit of mc. And IIRC, mc itself uses the '\007' (or "ST"?) escape to update the terminal title. Ah, "ST" is "ESC \" or, e.g.: $ PS1='$ ' $ printf '\033]0; allowTitleOps=yes\e\' I think, using 'ESC \' is a bit weird, as it looks as if the printf is not terminated, while it obviously is, if you try it. See: ==== man 4 console_codes ==== In addi- tion to the ECMA-48 string terminator (ST), xterm(1) accepts a BEL to terminate an OSC string. These are a few of the OSC control sequences recognized by xterm(1): ESC ] 0 ; txt ST Set icon name and window title to txt. [..] It accepts ESC ] (OSC) for the setting of certain resources. In addi- tion to the ECMA-48 string terminator (ST), xterm(1) accepts a BEL to terminate an OSC string. These are a few of the OSC control sequences recognized by xterm(1): ESC ] 0 ; txt ST Set icon name and window title to txt. ==== man 7 ascii ==== 007 7 07 BEL '\a' (bell) ==== man 1 xterm ==== In either VT102 or Tektronix mode, there are escape sequences to change the name of the windows. Additionally, in VT102 mode, xterm implements the window-manipulation control sequences from dtterm, such as resizing the window, setting its location on the screen. [..] allowTitleOps (class AllowTitleOps) Specifies whether control sequences that modify the window title or icon name should be allowed. The default is true. [..] SEE ALSO resize(1), luit(1), uxterm(1), X(), pty(4), tty(4) Xterm Control Sequences (this is the file ctlseqs.ms). http://invisible-island.net/xterm/xterm.html http://invisible-island.net/xterm/ctlseqs/ctlseqs.html ==== http://invisible-island.net/xterm/ctlseqs/ctlseqs.html ==== Operating System Commands OSC Ps ; Pt BEL OSC Ps ; Pt ST Set Text Parameters. For colors and font, if Pt is a "?", the control sequence elicits a response which consists of the con- trol sequence which would set the corresponding value. The dtterm control sequences allow you to determine the icon name and window title. Ps = 0 -> Change Icon Name and Window Title to Pt. ==== xterm*) PS1="\[\033]0;\u@\h[${TTY}]: \w\007\]${PS1}" ;; | ^^^^^^ ^^^^^^^^^^^^^^^^^ ^^ ^ end zero-width | | string `- BEL | `- "ESC ] 0 ;" == "OSC Ps ; Pt BEL" `- start zero-width See also the Bash-Prompt-HOWTO / Advanced ... (IIRC). Dabbling with that is both fun and frustrating... HTH, -dnh BUGS: THIS MAIL LOOKS CONFUSING! PS: I've been using this kind of setup for almost as long as I use linux / bash / xterm, i.e. ~20 years ;) [1] it's been _years_ if not a more than a decade since I've last dabbled with this, I am not sure why I used the sequence '\[ \010...\]' for stuff like the exit-code. I must've not worked without somehow. As both xterm and bash have evolved, I guess I should have another go ;) You're welcome to join weeding out the quirks when exit-codes get into the triple digits (Ctrl-c), TTYs into the doubles and paths into multiple lines ... In ~ and e.g. /tmp/ it should look as intended. And with exit-codes, it seems to work: dh@grusum[13]: ~ (0)$ false dh@grusum[13]: ~ (1)$ ^C dh@grusum[13]: ~ (130)$ true dh@grusum[13]: ~ (0)$ where the part up-to and including the ':' is white-on-blue (in my case) -- "Irrigation of the land with sewater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Thu, 07 Dec 2017, Carlos E. R. wrote:

On Thursday, 2017-12-07 at 19:30 +0100, David Haller wrote:

...

On Wed, 06 Dec 2017, Carlos E. R. wrote:

...

On Wednesday, 2017-12-06 at 09:00 +0100, David Haller wrote:

...

On Mon, 04 Dec 2017, Carlos E. R. wrote:

...

On Monday, 2017-12-04 at 13:58 +0100, David Haller wrote:

...

PS: my prompt is:

root@grusum[12]: ~ (0)# ^^^^ ^^^^^^ ^^ | | ` '#' for root, '$' for users | | | | `- last exit status (preserving "$?"[1]) user host | `- cwd `- tty/pts

Why? What interest is knowing the tty/pts? :-?

I start 8 xterms after logging in, with specified geometries and usually they're used for specific stuff. E.g. there's big main one where I do most work, and a few quite small ones for stuff like where I don't need to see much output, such as downloads.

Me too, but I differentiate them by their position, tittle, and workspace.

That too. But if I'm running stuff in multiple terms (say, 4 wget's) in those four small ttys, and want to do something about that, and use:

...

Ah, yes, I see. For instance "ps afxu | grep term" would list all terminals and their processes. You can identify the one that is stuck visually. Whereas I have to identify them by inspecting the output and guessing. It is difficult when several 'mc' are running to find in ps the one that I want.

ps afxu | grep pts

Jep. I just have to match tty/pts' from prompts/titlebars vs. ps output in some way or other. It is just nice (and at times very useful) to have that "link" via the tty/pts between the xterm and the processes running in it.

...

...

...

The tty/pts also shows up in the window title (which is often dynamically updated by running commands, but the prompt, including the pts, is kept), which helps to discern those 8+ xterm I have open in the window list. Compare the use of a window list of

dh@grusum: ~ dh@grusum: ~ dh@grusum: ~ [..] vs.

dh@grusum[1]: ~ dh@grusum[2]: ~ dh@grusum[3]: ~ [..] How do you get the window list like that? A command produces it?

Manual & copy & paste ;) Or do you mean how do I get the window-titles to reflect that? That's all in the PS1 magic:

No, I wondered if you had done copy-paste, LOL. You did :-)

C&P was just easier in this case, what with all those xterms littering the screen anyway ;) But, well, you can get that without C&P: $ xwininfo -root -tree -wm | pcregrep --only-matching=1 '.*? "([^"]*)":.*"xterm"' or $ xwininfo -root -tree -wm | awk -F'"' '/".*"xterm"/{print $2;}' dh@grusum[8]: ~ dh@grusum[13]: ~ [..] dh@grusum[3]: ~ [paths sedded to '~' for various reasons] See: xproperty: WM_NAME, see also man xprop. Only C&P involved here is from xterm to xemacs. Hm. Works from out of xemacs too via: ==== (defun sh-cmd-to-string (command) (interactive (list (read-shell-command "Command: " current-prefix-arg))) (message "" (call-process "/bin/sh" nil t t "-c" command))) ==== and then without any C&P involved ;) The builtin shell-command does not insert the output of the command into the buffer, which the above sh-cmd-to-string does ;) [pruning the paths would have to be done though]

...

==== ~/.bashrc ==== ### DO NOT 'export' TTY! ### TTY="$(tty)" TTY="${TTY##*[\/a-zA-Z]}"

# set prompt PS1="\[\033[1;37;44m\]\u@\h[ \[\010${TTY}\]]:\[\033[0m\] \w ( \[\010\$?\])\$\[\033[0m\] "

# set window title in xterm, reset to basic prompt in emacs case $TERM in xterm*) PS1="\[\033]0;\u@\h[${TTY}]: \w\007\]${PS1}" ;; *emacs*) PS1='\u@\h: \w $ ' ;; esac ====

I did tricks like those when I used MsDOS in the 80-90's. On Linux I haven't bothered :-)

Well, see above. Having the tty/pts in the prompt (and window title) can be quiet handy. Most of the "scary looking" stuff is just coloring anyway. Without any coloring and eliding the usually working magic for prompt-length, the prompt is just a much less scary: ==== PS1="\u@h [${TTY}]: (\$?) \w \$ " case $TERM in xterm*) PS1="\033]0;\u@\h[${TTY}]: \w\007${PS1}" ;; esac ==== That is not colorful, and ISTR that'd get garbled rather soon (once you hit 3digit exit-codes, double-digit pts', and esp. long paths etc.

...

...

...

And as I start those 8 via a script, I "know" that "[2]" is my main one at 103x44, and 3-6 are the small 81x10 terms...

I change the tittle in the script :-)

I "change" it with every command :P See the "magic" (see below) ESC ] 0 ; ${WHATEVER} \007 escape in my PS1 (for the case of an xterm).

The defaults should track "some" of the commands. But the current XFCE terminal is broken in that respect.

Seems to work here with xfce4-terminal-0.6.2. Should be able to test with 0.8.6 soonish.

...

Dabbling with [the bash-prompt and escape sequences to e.g. set window titles from PS1] is both fun and frustrating...

Huh. I guess it is.

Well, I've found a setup, a long long time ago that I was ok with, dabbling for 1-2 hours. See the above. And it has "saved my butt" quite a lot of times and made working much more comfortable, esp. while doing stuff locally and via ssh in parallel...

...

BUGS: THIS MAIL LOOKS CONFUSING!

That's an understatement :-P

*meh*

...

PS: I've been using this kind of setup for almost as long as I use linux / bash / xterm, i.e. ~20 years ;)

That explains it :-)

Time well spent once, I'd say. Read once, use for decades. I like that! Of course, there _have_ been tweaks at details. But the basic setup, the basic idea ... Same with mutt/procmail/{sendmail, now postfix}. Configure once, tweak as stuff comes up. My basic mutt/procmail setup dates from 2001. Can't remember when I switched from sendmail (also configured 2001 [2]) to postfix... But esp. the latter was configure and forget (basically, for my static setup)... All that stuff (but postfix) was _at the latest_ basically configured in my early SuSE 6.2 days. And I still use them. That then was time _well_ spent! -dnh [2] IIRC: I configured it once, lost the .m4 config file and yast just could not do what I needed. So, for years I tweaked the sendmail.cf directly. And was comfortable with it. Once you get the (very tight) syntax, it's not as bad as it may seem. You can copy rules/rulesets out of .m4 files provided, etc. And mind you: it was a mail on the german suse list that nudged me to dig into the documentation and find the solution for my problems setting up sendmail (the convenient m4 getting lost thereafter). But I'd gotten comfortable with the sendmail.cf. I did switch to postfix though. Sometime. And actually, for my setup, it is not easier to configure. I had to dig through _a lot_ of documentation until I got it right. relay/transport/sender/virtual/canonical/aliases/... Same concepts as in sendmail. Just differently configured. Just as hard to understand the inner workings. -- This space intentionally left aligned. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Thu, 21 Dec 2017, ken wrote:

On 12/07/2017 lotsa people talked about:

...

...

==== ~/.bashrc ==== ### DO NOT 'export' TTY! ### TTY="$(tty)" TTY="${TTY##*[\/a-zA-Z]}"

# set prompt PS1="\[\033[1;37;44m\]\u@\h[ \[\010${TTY}\]]:\[\033[0m\] \w ( \[\010\$?\])\$\[\033[0m\] "

# set window title in xterm, reset to basic prompt in emacs case $TERM in    xterm*)     PS1="\[\033]0;\u@\h[${TTY}]: \w\007\]${PS1}" ;; *emacs*)    PS1='\u@\h: \w $ ' ;; esac ====

After including the above in my .bashrc, tramp in emacs couldn't get in.  So in the noble FOSS tradition of Perpetual Tweaking, I added another line to the case statement which fixed that:

### DO NOT 'export' TTY! ### TTY="$(tty)" TTY="${TTY##*[\/a-zA-Z]}" # set prompt PS1="\[\033[1;37;44m\][ \[\010${TTY}\]]\u@\h:\[\033[0m\]\w( \[\010\$?\])\$\[\033[0m\] " # set window title in xterm, reset to basic prompt in emacs and via tramp case $TERM in    xterm*)      PS1="\[\033]0;[${TTY}]\u@\h:\w\007\] ${PS1}" ;;    *emacs*)    PS1='\u@\h: \w $ ' ;;    *tramp*)    PS1='\u@\h: \w $ ' ;; esac

==== case $TERM in    xterm*)      PS1="\[\033]0;[${TTY}]\u@\h:\w\007\] ${PS1}" ;;    *emacs*|*tramp*)    PS1='\u@\h: \w $ ' ;; esac ==== Well, dunno how that's in emacs with tramp, but my xemacs 21.5 reports a plain "emacs" as $TERM, so those '*' could be lost. Probably same with "tramp"... xterm though can be many things, most notably, it can be "xterm-256color" (and we care only about whether it accepts setting a window-title via "\e]0;..\007" or whether we should rather reset our fancy PS1 to a simple version...) $ echo $TERM xterm-256color Therefore the '*' at the end ;) Looking through /etc/termcap might be enlightning. And you might want to add one def for "tramp" (copied from the emacs* entry?) to that file (see 'less +/emacs /etc/termcap'). I find it somewhat weird though, that (X)Emacs of all editors has only a (sub-)shell that does not support common terminal behaviour... Oh, well, as I do not use emacs as a terminal, I don't care ;) Just if and when I do use it, setting PS1 to a value emacs can handle has proven, ahhm, a sensible choice :) Anyway: I'm quite flattered that you seem to like my prompt :)) I've wanted to weed out the quirks when the path/cmdline gets long, but I'm lazy and accustomed to it (for about 2 decades, bash 3.something IIRC). E.g. the "gobbling" of the last char at the end of a line of a "too long" command while C&Pasting. Often. Not always. Beats me why. Etc. I'd be happy if you find a tweak to amend this. But be reminded that PS1 get's evaluated every time the prompt is displayed (c.f.: -> "don't export the TTY variable", it'd change just as with commands (e.g. 'tty | sed') that'd get called for each prompt). And my intention was to have a "stable" connection between (x)term window / tty and prompt and process, so $TTY should stay the same from login to the tty/opening (x)term until exiting it. Actually, I think the static string ($TTY) should work. Instead of (all stuff about coloring and after the ':' elided): PS1="\u@\h[ \[\010${TTY}\]]: " this should work just as well: PS1="\u@\h[${TTY}]: " As $TTY should not change for the liftime of the shell (in the tty/(x)term)... *Duh* *facepalm* logic! And, lo and behold, that works with XEmacs too... Yep. *DOH!* Probably with Emacs and tramp as well. I.e your full prompt without xterm \007 stuff or resetting for emacs/tramp should be: ==== TTY=... # set prompt PS1="\[\033[1;37;44m\][${TTY}]\u@\h:\[\033[0m\]\w( \[\010\$?\])\$\[\033[0m\] " # set window title in xterm, reset to basic prompt in emacs and via tramp case $TERM... ==== [note the plain "[${TTY}]" sequence] The (<space>\[\010\$?\]) sequence seems to work at least for the most common (1-digit) exit-codes of 0 and 1. 2 and Ctrl-C / 130 is a bit weird anyway and depends on the interrupted program. Other exit codes are too rare to have me care for the last years ;) It'll still probably get screwed up on long prompts / exit-codes >= 10. Hm. I think I'll play with the prompt again, ISTR that printf was not a bash/posix-shell builtin back when, or at least I did not know about it. I guess I could live 3-digit exit-code. I'll have to try and think about that. Uh oh. Doesn't look good... Esp. the feat that it is _NOT_ reset by displaying it in the prompt. An "echo $?" at the prompt yields the correct value (and resets the value). With an embedded $(printf ...), that printf should set $?, and as it'd be run each time... *meh* Have I mentioned 'man 4 console_codes' in this thread already? Ahhh, I guess I'll have more fun (and frustration) again with the prompt. About the exit-code... Very nice to have. After years and years when I've been just too lazy to weed out the quirks ;)

This tweak also moved the TTY value to the beginning of the prompt to retain the string I often copy-n-paste, i.e., the "user@host:path" part.

Yeah :) Adoption, not plain simple C&P is right what I intended :) Same as with/without the space between the ':' and the path '\w'. Or '\W' as some might prefer, I hate the latter ;) I'm too often in two dirs called e.g. include, one e.g. /usr/include, the other /usr/local/include and '\W' does not help *at all* in those cases. But some seem to prefer '\W' in their prompt. I guess. Anyway: have fun playing with _YOUR_ prompt :) Keep it to your ~/.bashrc. C&P from your "user" to "root" ~/.bashrc, with a diffrent color (I use bold-white on red for root) is encouraged though ;) ==== /root/.bashrc ==== PS1='\[\033[1;37;41m\]\u@\h[ \[\010${TTY}\]]:\[\033[0m\] \w ($?)\$ ' case $TERM in xterm*) PS1="\[\033]0;ROOT CONSOLE [${TTY}]: \w\007\]${PS1}" ;; esac ==== (Yes, same old legacy "[ \[\010${TTY}\]]" sequence... I hope I did have a reason for that back when ;) And yep, a root-console get's a handy "ROOT CONSOLE [${TTY}]: ${PATH}" window title (instead of "user@host [${TTY}]: $PATH"). Easy to discern in my WMs window list ;) Works after a 'su -' too. # ps ax |grep '[p]ts/10' 28902 pts/10 Ss 0:03 bash 29126 pts/10 S 0:00 su - 29132 pts/10 S 0:00 -bash # pstree -p 28902 bash(28902)---su(29126)---bash(29132)---pstree(29240) Note: the tty/pts _stays_ where it was! Same xterm, same pts! ==== dh@grusum[10]: ~/foo (0)$ su - Password: [xterm title switches from "dh@grusum[10]: ~/foo" to "ROOT CONSOLE [10]: ~"] root@grusum[10]: ~ (0)# ==== *hehe* pts/10 stays pts/10 and is reflected in the prompt and xterm window title :) As is the intention of adding ${TTY} to the prompt at all. But the xterm's title *did* change :)

Thanks to all who really did all the heavy lifting for this code.

That'd be the authors of the Bash-Prompt-HOWTO and me in this case. AFAIK, including the tty/pts in this way was original. At least, I've not seen that elsewehere. Dunno about the exit-code. I just like having it in my prompt :) dh@grusum[6]: ~/foo (0)$ bleargh bash: bleargh: command not found dh@grusum[6]: ~/foo (127)$ false dh@grusum[6]: ~/foo (1)$ true dh@grusum[6]: ~/foo (0)$ ^C dh@grusum[6]: ~/foo (130)$ echo $? 130 dh@grusum[6]: ~/foo (0)$ echo $? 0 dh@grusum[6]: ~/foo (0)$ (note that $? stays at 130 for the first "echo" but gets set to 0 after the echo, as expected, i.e. the shell behaves "normal", just that the exit-status gets _displayed_ in the prompt, without changing it, the second echo echoes the exit-status of the first echo). HTH, HAND, & thanks, -dnh PS: $ echo $HISTSIZE $HISTFILESIZE 50000 500000 Yes, at around 100k cmds in ~/.bash_history, starting terms gets a bit slow (on my box, at 50k it's still snappy). But I'm at it. I wrote a script to uniq-add that to a "backup" history while keeping the chronological sequence of the commands (i.e. the last of each command)... But that's a whole other story ;) --

Train in the way you want to behave under pressure. Because the way you train *will* be the way you behave nuder pressure. The Typo Of The Month Contest is now closed for June. -- Ingvar the Grey and J.D. Baldwin

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, On Fri, 22 Dec 2017, ken wrote:

On 12/21/2017 05:56 PM, David Haller wrote:

...

On Thu, 21 Dec 2017, ken wrote:

...

On 12/07/2017 lotsa people talked about: .... ### DO NOT 'export' TTY! ### TTY="$(tty)" TTY="${TTY##*[\/a-zA-Z]}" # set prompt PS1="\[\033[1;37;44m\][ \[\010${TTY}\]]\u@\h:\[\033[0m\]\w( \[\010\$?\])\$\[\033[0m\] " # set window title in xterm, reset to basic prompt in emacs and via tramp case $TERM in    xterm*)      PS1="\[\033]0;[${TTY}]\u@\h:\w\007\] ${PS1}" ;;    *emacs*)    PS1='\u@\h: \w $ ' ;;    *tramp*)    PS1='\u@\h: \w $ ' ;; esac ==== case $TERM in    xterm*)      PS1="\[\033]0;[${TTY}]\u@\h:\w\007\] ${PS1}" ;;    *emacs*|*tramp*)    PS1='\u@\h: \w $ ' ;; esac ====

Well, dunno how that's in emacs with tramp, but my xemacs 21.5 reports a plain "emacs" as $TERM, so those '*' could be lost. Probably same with "tramp"...

Could well be.  "*tramp*" was a wild guess and it worked, so I went with it.  I understand the logic in removing asterisks.  But then code changes so fast that something which works today might not work next year, or even in three months, so there might be merit in sloppier definitions.  The only requirement for our purposes here is to select out a TERM variable... which is to say, eliminate all of those we don't want.

Yeah.

Playing around some more with emacs, I found that "M-x shell" makes the emacs window (aka "frame").  Our code in this window is a mess unless we make another change to accomodate the fact that this emacs shell uses a "dumb" TERM.  So...

Well, mine uses 'emacs' for TERM ;)

...    *emacs*|*tramp*|dumb)    PS1='\u@\h:\w $ ' ;; ...

...

Anyway: I'm quite flattered that you seem to like my prompt :))

Yeah, I should be paying bills, but I'm jazzed on this new prompt. :)  I especially like having the last error code show up in the prompt.  It actually happens a lot that I wanted to see what exit value some executable returned, but I forgot to append "echo $?" at the end of the invocation and I've already run another command since then.  Now the error code is *always* there-- for everything I run. Thanks.

Great!

...

I've wanted to weed out the quirks when the path/cmdline gets long, but I'm lazy and accustomed to it (for about 2 decades, bash 3.something IIRC).

E.g. the "gobbling" of the last char at the end of a line of a "too long" command while C&Pasting. Often. Not always. Beats me why. Etc.

I haven't seen this yet.  I'm currently using:

# set prompt PS1="\[\033[1;37;44m\][ \[\010${TTY}:\[\010\$?\]]\u@\h:\[\033[0m\]\w \$\[\033[0m\] " ^ BTW: you lost a ' ' at the ^ and as I said, no need for munging $TTY.

Make the term small and change into a deep dir, and you'll seen weird linebreaks/gobbled chars. ==== displayed as ==== [13:0]dh@grusum:/data/newsw/gcc-go/gccgo/libstdc++-v3 /te stsuite/18_support/headers/cstdint ==== I refined it now to: PS1="\[\033[1;37;44m\][${TTY}: \[\010$?\]]\u@\h:\[\033[0m\]\w $\[\033[0m\]" Which does linebreaks correctly as: ==== [13:0]dh@grusum:/data/newsw/gcc-go/gccgo/libstdc++-v3 /testsuite/18_support/headers/cstdint ==== My PS1 works better too now ;) But I get gobbled chars if I get long commands from history via "up" etc... YAY! I got it: PS1="\[\033[1;37;44m\]\u@\h[${TTY}]:\[\033[0m\] \w ( \[\010\010\010\$(printf '%03i' "\$?")\])\$ " and this should work for you: PS1="\[\033[1;37;44m\][${TTY}: \[\010\010\010\$(printf '%03i' "\$?")\]]\u@\h:\[\033[0m\] \w \$ " The magic that stops the garbling is: ' \[\$(printf '\b\b\b%03i' "\$?")\]' ^^^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^- end zero-space seq | | `- delayed exec of the printf, at each | | prompt, with printf as a builtin ... ;) | `- start zero-space seq ^- three spaces to reserve place Where the '\b\b\b' is the '\010\010\010' 3 backspaces to delete the reserved place. And the 'delayed-exec' of the printf always gives us 3 digits. Using '% 3s' or '%- 3s' works too.

...

.... The (<space>\[\010\$?\]) sequence seems to work at least for the most common (1-digit) exit-codes of 0 and 1. 2 and Ctrl-C / 130 is a bit weird anyway and depends on the interrupted program. Other exit codes are too rare to have me care for the last years ;)

It'll still probably get screwed up on long prompts / exit-codes >= 10.

This is a weird problem.  I too get the Ctrl-C error code 130 truncated to "1", but only when I'm remotely logged in to system. And then if I run "echo $?" it confirms with "1".  So that problem doesn't seem to have any relation to your code, but an anomaly when doing Ctrl-C to a remote system I ssh into.

Probably not truncated, but turned into a simple "false" ...

...

Have I mentioned 'man 4 console_codes' in this thread already?

I think all that is for if you make your prompt into a Pacman game. B^0

*hehe* There's 2-3 relevant sections: ESC- but not CSI-sequences (includes: ESC [ CSI Control sequence introducer and ECMA-48 CSI sequences [..] m SGR Set attributes (see below). [..] ECMA-48 Set Graphics Rendition 0 reset all attributes to their defaults 1 set bold 37 set white foreground 44 set blue background So, ESC [ -> CSI 1 -> SGR bold 37 -> white fg 44 -> blue bg m -> CSI SGR -> \033[1;37;44m and ESC [ -> CSI 0 -> SGR reset m -> CSI SGR -> \033[0m The movment CSI seqs might be interesting too for other stuff than PS1.

...

........

This new prompt would make a great holiday gift for all my friends and family, except none of them uses linux... and they'd be trying to figure out how to return it.

*heh* -dnh -- Perl isn't a programming language, it's a thousand special case rules flying in close formation. -- Peter da Silva -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org