Island of castaway thoughts - 2018-04-12

« first day (229 days earlier) ← previous day next day → last day (2170 days later) »

10:15 AM

@Zanna Cool! Does the anonymous feedback on it show that more users who may not have been able to vote found it useful. I'm curious if this is something a whole bunch of us noticed at once.

Btw in the end of your answer there, you say "Removing them would be a very bad idea?" But is that true, even for the package(s?) whose removal wouldn't cause anything else to be removed and that aptitude why revealed where installed just to satisfy a "recommends" dependency?

(I don't know the answer to this, in this particular case. I am not using "But is that true" as a euphemism for "I think you are mistaken." :)

@EliahKagan I do not think there will be any anonymous feedback available until after the weekend... Unless it's no longer the case that the data gets dumped (perhaps I should find a nicer verb for this) on a Sunday UTC morning...

@EliahKagan right I should clarify it. I could get away with removing kwayland-data which is only a dependency of something recommended by something depended on by Konsole, but I could not remove that package which libgtk-3-0 or whatever it is depends on, because ubuntu-mate-desktop will then have to be removed too

@Zanna Oh. Right!

but it would be interesting to know if others did notice the same thing and wondered about it

I will check for anonymous feedback after the weekend :)

11:06 AM

* can uncountable nouns outnumber each other...?

I think is meaningful and grammatical to say things like, "Anonymous feedback greatly outnumbers registered feedback," if that's what you mean.

yes that is what I mean. OK :)

OTOH I would not say, "Unreliable information outnumbers reliable information." Perhaps the feedback, in this context, has an associated number, in a way that information doesn't. I am not sure exactly when it makes sense to say things of the form, "ADJECTIVE UNCOUNTABLE-NOUN outnumbers ADJECTIVE UNCOUNTABLE-NOUN," and when it does not. (I'm not even sure that's the best way to formulate the question.)

Do you want to post a question about this on English Language & Usage?

I would say, "Link spam outnumbers other spam."

that seems an excellent idea... I will do that after making these almond cookies, unless you'd like to do so yourself, which would result in a better question...

make almond cookies yourself? ;D

I'd love to, but my baking skills are rather basic ;)

11:15 AM

@Zanna I'm inclined to wait for your question; I don't feel I'd ask it better. I'm willing to post one if you don't want to, but I don't think there's any hurry, so I'm perfectly content to wait.

I am a very careless baker, so it won't take me long hahaha

11:47 AM

Doesn't carelessness make things take longer, in the end?

definitely, if you insist on a high quality result

have posted my question

Thanks.

@Zanna of course, that should always be done. But I don't think I would do anything at all if I did so, because I am lazy

@Zanna Feel free to reject my edit suggestion if you don't think it's good or prefer not to retitle that way.

your edit suggestion makes me think that I don't understand my own question...

11:55 AM

That suggests you should perhaps reject my edit suggestion.

:)

The examples are things like "anonymous feedback" and "registered feedback."

Anonymous feedback is not a quantity of feedback, it's a kind of feedback.

I approved your suggestion

I hope you didn't accept my edit just to spare my feelings. I don't think I have any rejected edits on English Language & Usage so a rejection won't appreciably change the likelihood that I would receive a temporary edit ban on that site (not that this would be a reason to accept it otherwise).

no, your explanation enlightened me haha that's why I approved

I should probably have been more verbose in my edit summary then!

I should... write edit summaries D:

I see I have at least 2 badges (teacher and explainer) on that site that I got by answering a question, but the question was subsequently migrated, so, those badges are entirely undeserved!

12:02 PM

I think you are just saying that because you know that I post opinionated walls of text anytime anybody ever claims a specific behavior of the Stack Exchange system is fair or unfair. :)

12:24 PM

well, I do appreciate your helpful "opinionated walls of text"

@Zanna Thanks for editing that post. Sorry, I had said I would edit it with an explanation, but I couldn't figure out how to explain it well -- and you did. My edit from just now-ish is a more minor change but I still suggest that you look it over in case there's something you want to change.

I did not find a good source documenting sudo's behavior of having changes to PATH take effect when searching for the command, though I did find the corresponding source of information for env, so I removed the uncertainty from your statement about that an added a quote from it. Hopefully we'll find something to link to about sudo's behavior with sudo PATH=/whatever.

Also, there's something I thought of editing but didn't because I wasn't sure about it. You say:

> I don't need to export (and doing so does not help) because I don't need to pass this as an environment variable to any child processes of the shell.

I agree with your advice about not writing export. But unlike variables like PS1, the PATH variable is expected to be in the environment. I don't think external commands that don't receive it in their environment are actually required to work, in most cases. Instead, I think what's going on here is that PATH is already exported. There's no need to export it again.

If somehow it wasn't already in the environment, that would be weird and there would be no justifiable reason to mask the problem by exporting it upon modification.

@EliahKagan * sudo's behavior of not having changes to PATH take effect when searching for the command

12:59 PM

@EliahKagan thanks very much for editing again!

maybe that post will get there in the end...

@EliahKagan ah ok... hmm!

So is it specifically for PATH that sudo -E doesn't work on Ubuntu? On my 16.04 system:

ek@Io:~$ FOO=bar sudo -E printenv FOO
bar
ek@Io:~$ echo "$PATH"
/home/ek/perl5/perlbrew/bin:/home/ek/.sdkman/candidates/kotlin/current/bin:/home/ek/perl5/bin:/home/ek/.gem/ruby/2.3.0/bin:/home/ek/.local/bin:/home/ek/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
ek@Io:~$ PATH="$PATH" sudo -E printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

I had observed that before; I always figured it was the intended behavior of sudo -E on any system where sudo is configured to use secure_path. Is that not so?

man 5 sudoers tells us that we should be able to use -E to disable env_reset for commands that have the setenv flag, I think

@EliahKagan check man sudoers

gah, ninja'd

>__<

however, I certainly couldn't get it to work by adding setenv to Defaults or by specifying commands to allow SETENV

@ByteCommander only because I spent hours on this yesterday. I am more slug than ninja

:D

user image

1:09 PM

So the behavior of secure_path is completely subsumed under that of env_reset, such that anything that disabled env_reset is unaffected by secure_path?

How wide is your terminal? :)

sorry... can't format it readably! Evidently my terminal is too wide hahaa

Can't you just run COLUMNS=80 man sudoers or something?

@Zanna It is unclear to me if that is really saying secure_path only has any effect when env_reset is enabled. In the part of the manpage that documents secure_path itself, env_reset is not mentioned:

 secure_path   Path used for every command run from sudo.  If you don't
               trust the people running sudo to have a sane PATH environ‐
               ment variable you may want to use this.  Another use is if
               you want to have the “root path” be separate from the “user
               path”.  Users in the group specified by the exempt_group
               option are not affected by secure_path.  This option is not
               set by default.

(Yeah, man respects COLUMNS. I just tried, separately from that, with COLUMNS=60.)

 env_reset         If set, sudo will run the command in a minimal environ‐
                   ment containing the TERM, PATH, HOME, MAIL, SHELL,
                   LOGNAME, USER, USERNAME and SUDO_* variables.  Any
                   variables in the caller's environment or in the file
                   specified by the restricted_env_file option that match
                   the env_keep and env_check lists are then added, fol‐
                   lowed by any variables present in the file specified by

(Thanks.)

@ByteCommander omg you found a ninja slug!

if it had been clear to me what secure_path was supposed to do without env_reset, I would probably have posted it in my answer

1:17 PM

Yeah, that's also basically why I didn't try to add anything to (or remove anything from) that part. But you link to a post on Unix & Linux. That's to support the claim that sudo -E won't do what the OP wants on Ubuntu, right?

@EliahKagan yes...

I'm not sure I understand why it's a bug.

So it seems that, commenting out Defaults secure_path fixes the "problem" of sudo using secure_path. Commenting out env_reset doesn't fix the problem. So, secure_path works regardless of env_reset

so -E, which disables env_reset if setenv is set, does not disable secure_path...?

1:41 PM

spends ages editing the poorly formatted post, probably to little effect

1:51 PM

@Zanna Should -E disable secure_path?

To clarify why I am not clear on why the current behavior is considered a bug: the way that question that you linked to talks about it being a bug is that it says users have reported bugs about it on Launchpad. It links to three Launchpad bug reports, one of which is LP Bug #192651 and the other two of which are (currently) duped to it.

But that bug shows status Fix Released, not just upstream, but also in Ubuntu.

@EliahKagan I guess that is a matter of opinion :) What do the developers think?

Well... is the behavior described in the linked Unix & Linux question even the current behavior?

it seems so to me... -E doesn't stop secure_path from being used

uh oh... time to go to Tamil lesson

2 hours later…

3:36 PM

I am thinking there's something not right here because ./ is certainly a relative, not absolute path. But I realise that I don't know why Bash doesn't execute executable files in the current directory unless we use ./ to indicate we are passing a path and not just a random word that happens to match a filename in the working directory (also, I don't think that question is really a dupe...)

Yeah, it's the presence of a / character that causes the shell to treat it as a path.

You can use either a relative path or an absolute one.

Thanks! I'm on mobile and now going afk. I will try to remember to comment there later

I have posted a comment.

3 hours later…

6:28 PM

@EliahKagan thank you! Great comment

Is it actually clear from my comment that the / making the shell treat it as a path is why the / is needed? Rereading it now, I am not sure that is clear.

When we enter the name of a command in PATH, and the shell looks in our PATH for it and finds it, is it interpreted as a path?

Mobile chat bugs...

@Zanna No.

But are you just asking what I mean when I talk about a command name being interpreted as a path?

Like, what is the shell thinking? Is it going "is there a /usr/local/bin/foo? Nope, so is there a /usr/bin/foo? Nope, so is there a...

@EliahKagan yes, I suppose so

6:51 PM

By "interpreted as a path" I mean taken as identifying a specific file by one of its (hard) links located in a directory somewhere. So /bin/cat and ./cat interpreted as paths -- they identify a specific file by name, unless they fail to do so because there is no such entry.

In other contexts than looking up commands, just cat by itself is a perfectly good relative path, which is guaranteed to identify some file if and only if ./cat does and to identify the same file as it does if they identify a file. But when a (Bourne-style, or most other types of) shell decides what command is signified by the first word in a, er, command, it does not consider that to be a path.

@Zanna You/I/everyone should double check this to be sure but... A Bourne-style shell has, by this point, already performed any alias expansion, because that is part of the parsing phase that happened earlier. So the first thing it may ask, especially if it is trying to comply with POSIX, is, "Is there a POSIX special builtin called foo?" Nope. Then it asks, "Is there a shell function defined called foo?" Nope. (Unless you do have one, which will apply to all subsequent nopes.)

Then it asks, "Is there a (regular) builtin called foo?" Nope. Then, if hashing is enabled (set -h in bash and some other shells), which usually it is, then it asks, "Is there an external command whose filename is foo and whose path is stored in the hash table of currently accessible commands?" Nope.

Then it examines PATH (or equivalent -- it some shells store it as an array that gets updated automatically and use that) and asks things like, "Is there a /usr/local/bin/foo?" Nope. "Is there a /usr/bin/foo`. Nope. And so forth.

7:36 PM

sorry for asking a question and then vanishing... I had to walk home from the train station and it is for some reason extremely cold, such that using a touch screen was too uncomfortable, and for less mysterious reasons increasingly dark, such that looking where I was going seemed necessary

No problem.

@EliahKagan :)

@EliahKagan but when a [...] shell decides what command is signified by the first word in a command, it does not consider that to be a path

I don't understand

it does not consider it... to be a specific file

We use the term "command" to mean things like cd, ls, and so forth, but we also use it to mean a runnable unit of code.

yes

Oh, it's the other part you're asking about.

cat is an external command (unless you define a function called cat, or your shell has a cat builtin because it's busybox sh, or something) but when it reads your first word as cat, it does not take that as identify any specific file. It takes it as saying to look up a command whose name is cat. In contrast, it would ./cat or /bin/cat as a path, identifying a specific file by its location.

7:54 PM

so if I say cat, the shell goes "she wants me to run.... cat... is there POSIX special builtin called cat? Nope, so, is there a shell function defined called cat? Nope, so..." and so on until it either finds a cat somewhere or runs out of places to look, whereas if I say /bin/cat the shell executes the file (without thinking about it)?

Yeah. I should have said that first it asks, "Is there a / character in cat?"

Also, by default some shells -- at least bash -- don't distinguish between special and regular builtins and treat all builtins as regular unless in POSIX compatibility mode.

ah :)

@EliahKagan and if there is a / character in it, it will either (unthinkinkingly) execute the file, or complain that there is no such file, and not bother to start looking for in amongst functions/builtins/things in hash tables/stuff in PATH directories?

hmm maybe I am asking really silly questions

@Zanna I think that, if it is syntactically a valid path (whether or not there's anything there), then it will call one of the functions in the exec family (from libc6), and then if that fails, it will see if it can open it as a shell script, and if that fails, it will report an error with specific information.

Somewhere in there -- probably after exec-ing but before trying to run it as a script -- I think it checks if it has executable permissions. Any of the exec family functions will themselves fail if it doesn't, anyway.

I don't know how much the fine details of this vary between shells but I imagine it's considerable.

8:10 PM

(how did I end up with extra kin in my unthinkingly?)

in any case, I understand now! thank you for your patience in explaining this to me

I'm not totally sure about the quality of my explanation of this... but you're welcome.

I was going to say, to get at the whole thing another way: How the shell treats foo is different from how it treats foo/bar. It looks up foo, and one of the thing it eventually does, if it doesn't find it through other means first, is to look for it in all the directories listed in the value of the PATH variable.

It doesn't matter if there's a file called foo in the current directory, except coincidentally if one of the colon-separated pathnames in PATH happens to be a name for the current directory (which could happen if it's a fully qualified path, with or without some components being symlinks, or if it is ., etc.). It looks for it in all the PATH directories, in the order they are named.

yes

With foo/bar, there is no such search. For example, if one of the directories named in PATH contains a subdirectory foo which contains an executable bar, that will still not be run due to the command foo/bar, except coincidentally.

Another way to look at it is that, since PATH lookup need only be performed for names that could be filenames, there's no ambiguity in the syntax, and putting a slash character in the name is a perfect way to ensure you could only possibly mean to give the shell a path. If you don't give it a /, then it performs path lookup, using the directories in PATH. In Unix-style shells, . is not implicitly added to PATH, though you can add it, though you shouldn't.

however, if the current working directory contains a directory called foo which contains a file called bar, then the shell will try to execute it

@EliahKagan yes, putting . in the PATH must astronomically increase the chances of accidentally executing some harmful command...

Right, because foo/bar contains a /, and so the shell interprets it as a path, and it doesn't start with a /, so it is a relative path and its first component is taken to reside in the current directory.

8:21 PM

@EliahKagan it must surely also be faster to pass the shell a path than to force it to perform all that look-upping by typing some word that doesn't appear to be a path

Do you mean that /bin/cat would be faster than cat?

yes

Maybe. I am not sure it would be faster, and I expect that would vary across shells (and perhaps versions of the same shell).

If cat is not hashed, though, the yes, I would expect /bin/cat to be faster than cat.

we should probably migrate these messages to the Island too?

Well not the ones about the question that was migrated from main to meta. :)

But besides those, yes.

I can do it.

Should the messages about the sudo question be migrated too?

8:35 PM

I think so

@EliahKagan ah thank you! You are always doing that work...

You're welcome. I don't always do it, though. When you made the room, you went through who knows how much stuff and moved things carefully over.

:)

Before I move messages -- though it definitely does not have to be before I move them -- shall we see if we can figure out if there are any other edits that would make sense for the sudo post?

It might just be done. I am not sure.

@EliahKagan That answer is definitely a work in progress

8:58 PM

It seems Stéphane Chazelas expected sudo "PATH=$PATH" godi_console to work to find godi_console in $PATH. Of course it is possible for him to mistaken about stuff... but this nonetheless makes me wonder if there's something more going on than just sudo not have variable assignments affect path lookup. Still, I can pass PATH into the environment of a command just fine with that syntax.

I just haven't found anywhere the intended behavior for this is documented. As I mentioned, I had thought there was something on Ask Ubuntu about it, but I did not find that.

I also read that post by him

I'll be back in a bit and I can move messages then.

but still, it blatantly does not work

I remember having researched this before (a year ago or so). Clearly, I should do better research (carelessness always makes things take longer in the end!)

9:24 PM

(going to bed)

Good night!

:)

« first day (229 days earlier) ← previous day next day → last day (2170 days later) »

Transcript for

Apr '1812

Island of castaway thoughts

overly long technical / off-topic discussion bailed from the D...

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile