Dne čtvrtek 18. března 2021 14:02:14 CET, Anton Aylward napsal(a):

On 2021-03-18 7:09 a.m., David T-G wrote:

...

I don't like that code at all. It's guaranteed to succeed, whether .alias exists with a non-zero length and parses happily, or .alias doesn't exist, or .alias exists AND HITS A FAILURE, which doesn't make sense.

Oh, it DOES make sense. It HAS to succeed since this is in .bashrc. This is the bash start-up script. If that fails then the bash startup aborts.

Really? As any other BASH script, if You'd have in ~/.bashrc e.g. some custom function with syntactical error or so, at startup You get error about particular line and then the execution continues. I know it isn't optimal, but it seems to be working.

Think about the consequences of that in various contexts and you'll realise why that can't be allowed to happen.

Any example? Nothing cames to my mind... :( -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

Anton Aylward wrote:

This is the bash start-up script. If that fails then the bash startup aborts. Think about the consequences of that in various contexts and you'll realise why that can't be allowed to happen. I tested it. I inserted a "false" command in my ~/.bashrc, which returns an exit code 1.

[...] test -s ~/.alias && . ~/.alias || true false export DISPLAY LESS PS1 PS2 umask 022 [...] Login works correct. There is also no error message during login. Even "false" as the last ~/.bashrc command works. Greetings, Björn

On 2021-03-18 06:09:40 David T-G wrote:

|Vojt??ch, et al -- | |...and then Vojt??ch Zeisek said... |% |... |% # Alias |% test -s ~/.alias && . ~/.alias || true |% |... |% For more information: |% https://www.shellcheck.net/wiki/SC1090 -- Can't follow non-constant | source.... % https://www.shellcheck.net/wiki/SC2015 -- Note that A && B | || C is not if-t... % |% The second warning SC1090 seems like false positive (waiting for some |% ShellCheck update), but the first SC2015 seems like really problematic |% code, but I'm not sure if I fully get what's going on in this |% syntactical cleanup. What should be the super clean correct code here? |% Is this default worth of change? | |I don't like that code at all. It's guaranteed to succeed, whether .alias |exists with a non-zero length and parses happily, or .alias doesn't exist, |or .alias exists AND HITS A FAILURE, which doesn't make sense. | |Much better would be | | test ! -s ~/.alias || . ~/.alias | |(perhaps with an escaped bang) so that when it is sourced you get the |actual result code out of it. | |As for SC1090, the parser can't give a final answer because the flow |depends on executing code. It's simply warning you that the results are |incomplete.

I have a number of places in my .bashrc that source other files. They have no test code around them at all, because I want to know if they don't work; bash complains if something goes wrong, but continues processing the rest of .bashrc. Leslie -- openSUSE Leap 15.2 x86_64

Vojt??ch, et al -- ...and then Vojt??ch Zeisek said... % % Dne sobota 20. b??ezna 2021 4:47:37 CET, David C. Rankin napsal(a): % > On 3/18/21 3:09 AM, Vojt??ch Zeisek wrote: % > > $ shellcheck -o all ~/.bashrc ... % > > test -s ~/.alias && . ~/.alias || true % > > ^-- SC2015: Note that A && B || C is not if-then-else. C % > > may run when A is true. ... % Interestingly it's same: % % $ shellcheck -x -o all ~/.bashrc % % In /home/vojta/.bashrc line 19: % test -s "${HOME}"/.alias && . "${HOME}"/.alias || true % ^-- SC2015: Note that A && B || C is not if-then- % else. C may run when A is true. ... % It seems the real syntactical problem is SC2015 "A && B || C is not if-then- % else. C may run when A is true." https://github.com/koalaman/shellcheck/wiki/ % SC2015 I would argue against that. The message is accurate and it is warning you about a condition that many may not recognize, perhaps with terrible consequences. % % Editing it as % % # Alias % # shellcheck source=/home/vojta/.alias % { test -s "${HOME}"/.alias && . "${HOME}"/.alias; } || true % % seems to be the correct syntax --- at least id doesn't report any ShellCheck % warning --- I'm just unsure if this is the desired behaviour. :-) Since && and || are of equal precedence, encapsulating like that does not change the behavior and thus does not mitigate against the possible problem. Something like A && { B || C } would, though; if A returns false, then nothing on the right is attempted. So for the original problem, I still say that it's bad distribution code and that it should be changed, and if someone will point me in the right direction with instructions suitable for a 5-year-old I will be happy to report it as a bug. For Vojt??ch's specific problem, if you don't mind that you'll always get a true (exit code 0) result out of the .alias line, then you're fine, but rewrite it as test ! -s "$HOME/.alias" || . "$HOME/.alias" if you want to catch any errors out of the .alias file BUT get a 0 whether the file doesn't have any content or runs successfully. HTH & HANN :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

Vojt??ch, et al -- ...and then Vojt??ch Zeisek said... % % Dne ned??le 21. b??ezna 2021 6:02:42 CET, David T-G napsal(a): % > Vojt??ch, et al -- % > ...and then Vojt??ch Zeisek said... % > % Dne sobota 20. b??ezna 2021 4:47:37 CET, David C. Rankin napsal(a): % > % > On 3/18/21 3:09 AM, Vojt??ch Zeisek wrote: ... % > % # shellcheck source=/home/vojta/.alias % > % { test -s "${HOME}"/.alias && . "${HOME}"/.alias; } || true % > % seems to be the correct syntax --- at least id doesn't report any ... % > Since && and || are of equal precedence, encapsulating like that does % > not change the behavior and thus does not mitigate against the possible % > problem. % % AFAIK '{ A && B; } || C' means that *if both* A and B are TRUE, C is skipped; % and *if any of* A or B is FALSE, then C is executed, isn't it? That is correct. That is also the exact behavior without the braces. Whip up a quickie script davidtg@u17383850:/tmp/and-or> ls -goh total 4.0K lrwxrwxrwx 1 7 Mar 23 08:46 Af -> testing lrwxrwxrwx 1 7 Mar 23 08:46 At -> testing -rwxr-xr-x 1 109 Mar 23 08:46 testing davidtg@u17383850:/tmp/and-or> cat testing #!/bin/sh F=`basename $0` case $F in *t ) echo "$F - T" ; exit 0 ;; *f ) echo "$F - F" ; exit 1 ;; esac davidtg@u17383850:/tmp/and-or> ./Af Af - F davidtg@u17383850:/tmp/and-or> echo $? 1 davidtg@u17383850:/tmp/and-or> ./At At - T davidtg@u17383850:/tmp/and-or> echo $? 0 and go and play :-) % % > Something like % > A && { B || C } % > would, though; if A returns false, then nothing on the right is % > attempted. % > So for the original problem, I still say that it's bad distribution code % % If it is, it can be reported at https://bugzilla.opensuse.org/ and fixed, I'm % just still unsure what's the best alternative, thought... :-( No worries. I'm happy to go and chase that, presuming that that bugzilla is the right one to use. % % > to report it as a bug. % > For Vojt??ch's specific problem, % % It's not really my specific problem, I was just wondering if default code % shipped by openSUSE is the bes one. :-) Fair enough :-) % % > if you don't mind that you'll always get a true (exit code 0) result % > out of the .alias line, then you're fine, but rewrite it as % > test ! -s "$HOME/.alias" || . "$HOME/.alias" % > if you want to catch any errors out of the .alias file BUT get a 0 % > whether the file doesn't have any content or runs successfully. % % Hmmm... Exactly :-/ % % -- % Vojt??ch Zeisek % https://trapa.cz/ Have a great day! :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

David, et al -- ...and then David C. Rankin said... % % On 3/20/21 9:47 AM, Vojt??ch Zeisek wrote: % > else. C may run when A is true. % > ^--------------^ SC1090: Can't follow non- % % This is okay here, since you must return true no matter what happens to % prevent a false being taken as an error and impacting shell startup. Again, I disagree. This is probably a religious^Wphilosophical difference, but IMHO it is better to fail upon a failure, even if that means that your login is interrupted and you have to fix it, than to quietly mask the failure. The trivial unset TARGETDIR # something failed; this is empty cd $TARGETDIR rm -rf * is one obvious example. There are many other less-obvious ways to screw up almost as badly. Realistically, this || true isn't even necessary; either you're the type to set -e and die on a failure or you aren't and the failure goes unnoticed. For those who DO care, though, this structure masks an error that would have been caught. % % So even if C runs returning true after A returns true -- that's fine. Sure, that's fine -- unless you need to know that B returned false. % % -- % David C. Rankin, J.D.,P.E. % Have a great day! :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

Linda, et al -- ...and then L A Walsh said... % % On 2021/03/23 05:57, David T-G wrote: % >Again, I disagree. This is probably a religious^Wphilosophical % >difference, but IMHO it is better to fail upon a failure, even if that % >means that your login is interrupted and you have to fix it, than to % >quietly mask the failure. The trivial % ---- % Uh...If you can't login and you are logging in remotely, you % are saying it is better for you to have to abort your vacation % in ....wherever... I think that might be defined as % self-masochism. No, I wouldn't say that at all. I would become root -- which I would in advance make darned sure didn't have any stupid errors that would blow up a shell -- and go and fix the stupid user's problem. And I wouldn't be the one on call while I'm on vacation, either :-) More to the point, I have not yet seen an error which would actually cause a login to fail and leave me not at a shell prompt. I would be very interested in seeing an example of that; that would be new to me. Not getting my standard config and my favorite aliases and my cute prompt and anything else set in run commands files, yeah; that's old news. But "can't login"? Haven't seen it yet. Of course, the user stupid enough to do this to himself[1] is probably also too dumb to fix it, so it will result in a support ticket anyway, BUT the occasional clever one who was smart enough to start poking around in the first place might get himself up and going again. % % Always better for system to come up usable and send off an % email to root if it is that serious (assuming root is forwarded to % you). [snip] I'm going to take the liberty of snipping the rest because I agree wholeheartedly with a belt-and-suspenders approach of catching errors and not doing stupid things and blah blah blah :-) [1] Yes, womyn can stupid themselves, too; I'm being general but with proper plurality :-) HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

Dave, et al -- ...and then Dave Howorth said... % % On Wed, 24 Mar 2021 09:09:49 -0400 % David T-G wrote: % % > No, I wouldn't say that at all. I would become root % % I'd expect any system that was capable of being remotely accessed to % disallow direct ssh or other access as root? Makes sense to me, but sudo or even su (ew!) will still work. HANN :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

Dave, et al -- ...and then Dave Howorth said... % % On Thu, 25 Mar 2021 22:06:00 -0400 % David T-G wrote: % % > Makes sense to me, but sudo or even su (ew!) will still work. % % Well if root login is disabled and if normal login fails, how do you % get a session to use the su command? Again, I have never in my recollection come across such a problem, and I would honestly and really be very interested in seeing a reproducible example of such a configuration problem that "|| true" would fix. % % PS Please don't send me private copies of mails. I'll try to remember :-) HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

Dne pátek 26. března 2021 10:25:45 CET, Dave Howorth napsal(a):

On Thu, 25 Mar 2021 22:06:00 -0400 David T-G wrote:

...

Dave, et al -- ...and then Dave Howorth said... % On Wed, 24 Mar 2021 09:09:49 -0400 % David T-G wrote: % > No, I wouldn't say that at all. I would become root % I'd expect any system that was capable of being remotely % accessed to disallow direct ssh or other access as root?

Makes sense to me, but sudo or even su (ew!) will still work.

Well if root login is disabled and if normal login fails, how do you get a session to use the su command?

On physical machines I have IPMI, on VM access to hypervizor (Proxmox etc.), both accessible via VPN from outside networks. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

On 24/03/2021 14.09, David T-G wrote:

Linda, et al --

...and then L A Walsh said... % % On 2021/03/23 05:57, David T-G wrote: % >Again, I disagree. This is probably a religious^Wphilosophical % >difference, but IMHO it is better to fail upon a failure, even if that % >means that your login is interrupted and you have to fix it, than to % >quietly mask the failure. The trivial % ---- % Uh...If you can't login and you are logging in remotely, you % are saying it is better for you to have to abort your vacation % in ....wherever... I think that might be defined as % self-masochism.

No, I wouldn't say that at all. I would become root -- which I would in advance make darned sure didn't have any stupid errors that would blow up a shell -- and go and fix the stupid user's problem. And I wouldn't be the one on call while I'm on vacation, either :-)

More to the point, I have not yet seen an error which would actually cause a login to fail and leave me not at a shell prompt.

I have. More than once on these mails lists or other places. I do not remember particulars, but the most typical one is a missing /home mount, full home, read-only home, etc. Me myself, too, no more than a year ago. Having that as a result of changing the defaults in bash or whatever... I remember one not two years ago, but again, not the details or how to google it. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

On 26/03/2021 03.10, David T-G wrote:

Carlos, et al --

...and then Carlos E. R. said... % % On 24/03/2021 14.09, David T-G wrote: ... % > % >More to the point, I have not yet seen an error which would actually % >cause a login to fail and leave me not at a shell prompt. % % I have.

Once again, I honestly would very much love to see a detailed and reproducible example of such a failure.

I can't remember the exact details of all the things that happened to me... the last incident was a "/home" that failed to mount (I don't remember why, but it was my fault), and login as user did not succeed. The machine was local, so no big problem. If that happened to a remote machine with root login disallowed, I would have been stuck. ...

So, no, I'm still not convinced. I really am interested, though. Surely some current and practicing SA can point to a real failure scenario that I could duplicate for fun and to perhaps be convinced. Anyone? Bueller?

The next time it happens or I see someone posting about it, I'll try to remember and tell you :-D Wait, google '"can not login" linux'. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

Carlos, et al -- ...and then Carlos E. R. said... % % On 23/03/2021 13.57, David T-G wrote: % > % >Again, I disagree. This is probably a religious^Wphilosophical % >difference, but IMHO it is better to fail upon a failure, even if that % >means that your login is interrupted and you have to fix it, than to % >quietly mask the failure. % % How are you going to fix it if your can not login? See my note to Linda's email a moment ago. The short form here is "I've never seen a case such that I can't login, and I would be very interested in an example." Thanks & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt