| AlexLikeRock | help | 00:48 |
|---|---|---|
| AlexLikeRock | aptitude install -t deadalus-backports thunderbird | 00:48 |
| AlexLikeRock | 00:48 | |
| AlexLikeRock | E: The value 'deadalus-backports' is invalid for APT::Default-Release as such a release is not available in the sources | 00:48 |
| gnarface | you spelled daedalus wrong | 00:49 |
| AlexLikeRock | yes, thanks | 00:50 |
| AlexLikeRock | jejej | 00:50 |
| AlexLikeRock | daed = dead | 00:51 |
| AlexLikeRock | something in my brain is wrong because of so many horror video games, like silent hill. | 00:51 |
| AlexLikeRock | heheheh | 00:55 |
| systemdlete | I might just be losing my mind (once more), but isn't shell supposed to find executables by examining the PATH envar? I am seeing some behavior that seems to be at variance with this. I've been using shells for 45 years and I've never seen anything like this before. I MUST be overlooking something. | 01:37 |
| systemdlete | afaik, I am not aliasing the command. It's a shell script, which I am running from the current directory I am in. But the PATH does NOT include "." (at, say, the beginning of $PATH), and the current directory is NOT in the PATH either. | 01:38 |
| systemdlete | Is there some option set somewhere that allows the shell to look at the current directory for executables? Or does it work differently for shell scripts? | 01:39 |
| systemdlete | Oh, this is bash. Maybe there are some new semantics added recently I am not aware of. | 01:39 |
| systemdlete | (but I doubt it) | 01:39 |
| systemdlete | I tried "hash -r" to see if maybe something was sticking in the interpreter's brains. | 01:40 |
| rrq | on can run ./script also in scripts | 01:43 |
| systemdlete | ? | 01:43 |
| systemdlete | I'm not running it as "./xyz" just as "xyz" | 01:44 |
| systemdlete | no relative path, no | 01:44 |
| systemdlete | (sorry that was not clear) | 01:44 |
| rrq | what does `which xyz` say? | 01:44 |
| systemdlete | shows me current directory pathname | 01:44 |
| systemdlete | oh wait | 01:45 |
| systemdlete | no | 01:45 |
| systemdlete | it actually says "./xyz" | 01:45 |
| systemdlete | but "." is NOT in my PATH | 01:45 |
| systemdlete | this doesn't happen in other directories. This is in a mounted fs /opt | 01:45 |
| rrq | I guess you've verifide (many times).. echo $PATH | 01:46 |
| systemdlete | so if I copy xyz to /tmp, e.g., and try to do the same thing, it won't run. I have to explicitly state the path or use relative ./xyz | 01:46 |
| systemdlete | what is "verifide"--(my english is good, but maybe not perfect) | 01:47 |
| systemdlete | the current working directory is NOT in my PATH envar | 01:47 |
| rrq | (sorry my fingers swapped) ... and there is no empty element in $PATH | 01:48 |
| systemdlete | no, no "::" anywhere in it | 01:48 |
| rrq | like ending in : or having :: | 01:48 |
| systemdlete | nope | 01:48 |
| rrq | and `/usr/bin/which xyz` says ./xyz | 01:49 |
| systemdlete | hmmmm. interesting: set -x shows that command is not found! And doesn't run the script. But if I turn it off again, it acts normally again. | 01:50 |
| systemdlete | wtf????? | 01:50 |
| systemdlete | set -x healed the problem ??????!!!!! | 01:50 |
| systemdlete | btw, echo $0 shows /bin/bash, not -bash | 01:52 |
| systemdlete | Idk if maybe that had something to do with it | 01:52 |
| systemdlete | I hope this VM is not diseased... | 01:52 |
| rrq | in my mind: the command line in bash does include aliases and functions ahdn hashed resolutions, all before resolving the command word bmo path | 01:54 |
| systemdlete | yes, and I checked for that. | 01:54 |
| systemdlete | I saw nothing. | 01:54 |
| systemdlete | sorry, I just looked again, and it is a -bash after all. the parent is a /bin/bash | 01:55 |
| rrq | and the local directory is not found as a $PATH point ?? with possible links etc? | 01:56 |
| systemdlete | but the short story is (TL;DR version) is that by calling "set -x" running the script (fails of course) and then "set +x" it unscrews the problem. | 01:56 |
| systemdlete | no, and no | 01:56 |
| systemdlete | (I checked that also before hitting the channel here) | 01:57 |
| systemdlete | (but still good to ask me) | 01:57 |
| systemdlete | yeah, I looked for links, aliases, envars (including PATH, LD_LIBRARY_PATH, etc) | 01:57 |
| rrq | and LD_PRELOAD | 01:57 |
| systemdlete | I know LD_LIBRARY_PATH should not influence this, but I was checking everything | 01:58 |
| systemdlete | not set | 01:58 |
| systemdlete | LD_PRELOAD is not in my environment | 01:58 |
| rrq | hmmm some bash completion activity? ... is there some "pre-command-execution" bash variable | 01:59 |
| systemdlete | env |grep bash shows just SHELL=/bin/bash | 02:00 |
| systemdlete | but that might not be thorough enough | 02:00 |
| systemdlete | I opened another shell window (XFCE) and I don't see the original behavior there. It seems to have jsut been this one shell | 02:01 |
| systemdlete | what is the ps fu for listing all the processes whose ppid is x? | 02:01 |
| rrq | any "trap DEBUG" setting? | 02:01 |
| systemdlete | trap (with no args or options) shows nothing | 02:01 |
| systemdlete | oh, nvm. --ppid | 02:02 |
| rrq | ps -lww $(ps -hoppid,pid | awk '$1='$PPID'{print $2;}') | 02:02 |
| rrq | ah --ppid is easier :) | 02:03 |
| systemdlete | ps -f --ppid is shorter, but thanks for the effort! | 02:03 |
| systemdlete | I missed it the first 2 times I scanned the ps man page | 02:03 |
| systemdlete | I never noticed this before, but xfce-terminal launches all the shell windows. For some reason, I thought each shell was launched by a xfce4-terminal instance. Dumb me. | 02:04 |
| systemdlete | til | 02:04 |
| systemdlete | well, rrq, I may have picked your brains thoroughly enough. I will wait and see if I notice this again and come back here with the evidence. | 02:05 |
| systemdlete | that is so weird how setting trace and unsetting it "fixed" the problem. | 02:06 |
| systemdlete | again, it was only happening in one directory | 02:06 |
| rrq | yes.. that suggests some hashing I guess | 02:06 |
| systemdlete | a giant security hole even if it is somehow intermittent | 02:07 |
| rrq | did you experiment and try using other than xyz name ? if that command name is special (sometimes)... | 02:08 |
| systemdlete | oh, actually I used "tst" after my original script (by a diff name) started doing this | 02:09 |
| systemdlete | I wrote a short and dirty one liner, put exec perms on it, and tested that script | 02:09 |
| rrq | "When bash is not in posix mode, it searches the current directory if no file is found in PATH." | 02:09 |
| systemdlete | got the same behavior (before I tried the set -x/set +x thing) | 02:09 |
| systemdlete | ah | 02:09 |
| rrq | that's for the "source" command | 02:10 |
| systemdlete | good catch!!! | 02:10 |
| systemdlete | so set +x threw the shell back into posix mode then? | 02:10 |
| systemdlete | is there a way to get the posix mode ? | 02:12 |
| systemdlete | I have another window where the issue is happening | 02:12 |
| systemdlete | and I know why this window is different: I launched it via ssh. | 02:13 |
| systemdlete | so it is a /bin/bash not a -bash | 02:13 |
| systemdlete | it is interactive and works fine, but it does not seem to know it is | 02:13 |
| systemdlete | so I am launching it (from Desktop file) as | 02:14 |
| rrq | env POSIXLY_CORRECT is set in posix mode | 02:14 |
| systemdlete | xfce4-terminal -e "ssh myuser@localhost" -T windowtitle | 02:15 |
| systemdlete | well, normal window (using default launcher as installed by system originally) correctly fails to find the "tst" script in the cwd, but echo $POSIXLY_CORRECT is not set | 02:16 |
| systemdlete | so none of my shells are politically correct then :( | 02:17 |
| systemdlete | but the ssh explains why I am seeing the behavior, POSIXLY_CORRECT notwithstanding | 02:17 |
| systemdlete | ok, now things make sense at least | 02:17 |
| systemdlete | I could have rubber ducked this, but chatting with you probably saved a lot of time | 02:18 |
| systemdlete | and you gave me some good ideas for next time I am trying to figure something like this out | 02:18 |
| rrq | cheers | 02:19 |
| systemdlete | but, rrq, I wonder if there could be security considerations for this | 02:19 |
| systemdlete | hopefully, no untrusted user would gain ssh access to a system in the first place, but still | 02:20 |
| systemdlete | yeah, thanks. later, unless you have more to suggest | 02:21 |
| rrq | I'm emptied for now :) | 02:21 |
| systemdlete | nw | 02:21 |
| rwp | systemdlete, Is /tmp a mount point mounted with the noexec option? | 06:00 |
| rwp | Though I may be misunderstanding your problem. | 06:01 |
| rwp | Note that back 45 years ago it was typical to have '.' in PATH but now that is seen as bad practice due to social engineering attacks and so now '.' is never in PATH by default and it is considered bad practice now. | 06:01 |
| rwp | Meaning that if it is in the current directory then you must use ./foo to execute it. | 06:02 |
| fluffywolf | I once had fun crafting malicious filenames with terminal escape sequences in them on a sunos box... having . in $PATH would have been even more options for fun. :P | 06:18 |
| systemdlete | I do not add "." to my path, ever. And, yes, 45 years ago it really was typical to add it to the path (if it wasn't already). | 06:27 |
| systemdlete | the /tmp wasn't where the problem was occurring. It was on a different file system. | 06:27 |
| systemdlete | just to clarify | 06:27 |
| systemdlete | yes, the /tmp file system is mounted with noexec. But so is the other one. | 06:28 |
| systemdlete | the mount options are identical, in fact, I just noticed | 06:39 |
| systemdlete | rwp, I think the distinction comes down to whether the shell is invoked as /bin/bash (as with ssh) or as -bash (as with local xfce terminals). | 07:14 |
| joerg | >><systemdlete> it actually says "./xyz" <systemdlete> but "." is NOT in my PATH<< tried `rehash` ? (alias `hash -r' ) | 17:01 |
| joerg | hash: hash [-lr] [-p pathname] [-dt] [name ...] | 17:03 |
| joerg | Remember or display program locations. | 17:03 |
| joerg | bash builtin | 17:03 |
| joerg | also `hash -t xyz` [analog to `which xyz`] - *prior to* a `hash -r` ;-) | 17:09 |
| joerg | oh sirry, missed the >><systemdlete> I tried "hash -r"<< | 17:15 |
| joerg | what is >>it is a -bash<<? | 17:20 |
| joerg | >>shell is invoked as […] -bash<< doesn't make sense to me | 17:21 |
| rwp | If systemdlete were here I would ask, And what is that difference that you observe is causing you problems? | 17:44 |
| rwp | When invoked as /bin/bash or bash then bash reads ~/.bashrc only and no other file but will inherit some environment from the calling process. | 17:45 |
| rwp | When invoked as -bash then it is a login shell and after inheriting whatever environment it will read .bash_profile or .profile and then do whatever it is instructed to do there and will NOT read ~/.bashrc by default but only if instructed in a profile. | 17:46 |
| rwp | WHen invoked as #!/bin/bash then it is a non-interactive script and if $ENV is set then will read it. Best never to set ENV because it is a breaker of scripts most often. | 17:47 |
| joerg | -bash: -bash: command not found | 22:12 |
| fsmithred | Yeah, I was wondering if maybe it's supposed to be 'bash -' which is the same as 'bash --' | 22:51 |
| fsmithred | to mark the end of options | 22:51 |
| AlexLikeRock | 0/ | 22:55 |
| yeti | login shells appear as -/bin/bash in the ps list, but I think they getr started via bash --login or ... -l | 23:10 |
| yeti | """yeti 2362 0.0 0.0 11308 4056 pts/1 Ss+ Jul27 0:00 -/bin/bash | 23:10 |
| yeti | """ | 23:10 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!