Summary: | baselayout does not protect against function env pollution | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Philip Hazel <ph10> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED WONTFIX | ||
Severity: | minor | ||
Priority: | High | ||
Version: | 1.4 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | strace log as requested |
Description
Philip Hazel
2003-10-07 04:32:34 UTC
Guess we could do a: unalias -a somewhere ... Unalias -a copes with aliases, but not with shell functions, which is what I happen to have used. You have to use "unset" to kill functions. There doesn't seem to be an obvious "kill all functions", (or maybe I've just missed it) but unset cp ls mv rm .... for all the "obvious" commands would be better than nothing. I find it hard to believe this is a problem. Scripts using #!/bin/bash and #!/sbin/runscript are not subject to .bashrc and friends. Additionally it is impossible to export shell functions or aliases to the environment. Only variables can be exported. If you are having a problem with /sbin/depscan.sh or other scripts within Gentoo, please post some debugging output demonstrating how you arrived at this conclusion. I'm closing this WORKSFORME until then, please re-open if you can provide more information. You commented "Additionally it is impossible to export shell functions or aliases to the environment. Only variables can be exported." Well, my shell functions seem to be exported. At least, that's what this seems to show: $ type ls ls is a function ls () { command ls $MY_LS_OPT "$@" } $ /bin/sh -c 'type ls' ls is a function ls () { command ls $MY_LS_OPT "$@" } $ My functions are defined in .bash_profile, and are explicitly exported. The bash man page says about "export": "The supplied names are marked for automatic export... if the -f option is given, the names refer to functions." That seems definite enough, doesn't it?? Another example: I run "rm" as a function with -i as the default; I get prompted when I replace a file using etc-update. I don't mind this, but it shows that functions are exported. (In reply to comment #4) > You commented "Additionally it is impossible to export shell functions or > aliases to the environment. Only variables can be exported." correct > Well, my shell functions seem to be exported. no they arent ... the only thing you may be showing is that your shells are auto-sourcing files again before execution > $ type ls > ls is a function this shows the local shell env, has nothing to do with what is/isnt exported > $ /bin/sh -c 'type ls' this is weird ... try running: strace -f -o ~/log /bin/sh -c 'type ls' then post the log file as an attachment > My functions are defined in .bash_profile, and are explicitly exported. The > bash man page says about "export": "The supplied names are marked for > automatic export... if the -f option is given, the names refer to functions." > That seems definite enough, doesn't it?? no, functions are marked for export *to subshells* > Another example: > I run "rm" as a function with -i as the default; I get prompted when I > replace a file using etc-update. I don't mind this, but it shows that > functions are exported. incorrect example ... your /etc/etc-update.conf file defaults to passing -i to rm and other commands Created attachment 73282 [details]
strace log as requested
Wow! It's 2 years since this thread was opened, and over a year since the last comment. As I said earlier, it really is a minor thing, and certainly not worth spending a lot of time on. > this is weird ... try running: > strace -f -o ~/log /bin/sh -c 'type ls' Done. > no, functions are marked for export *to subshells* Well, yes. They wouldn't be much use to anything else. > > no, functions are marked for export *to subshells* > > Well, yes. They wouldn't be much use to anything else. executing scripts which have '#!/bin/bash' as their interpreter are not subshells, thus functions wouldnt be exported to them thats the point agriffis was trying to make when he said that exporting functions to init.d scripts didnt make any sense > executing scripts which have '#!/bin/bash' as their interpreter are
> not subshells, thus functions wouldnt be exported to them
What about this evidence then?
$ cat zz
#! /bin/bash
type ls
$ ./zz
ls is a function
ls ()
{
command ls $MY_LS_OPT "$@"
}
It seems to me that that shows that the function "ls" is being exported. Or am I
completely mad? Or possibly not understanding what you mean by "executing scripts"?
that is what we're talking about how are you declaring the function ? bash has a hack which allows it to export functions to other processes by hiding them as variables, which is what you're seeing $ function foo() { echo bar; } $ env | grep ^foo= $ export -f foo $ env | grep ^foo= foo=() { echo bar so the previous statements stand ... functions are passed to subshells only, but if you use 'export -f', bash will stuff a function into an environment variable which will be passed to children processes which bash will then restore automatically as a function Yes, I am using "export -f", which (phew!) finally explains what is going on. From a user's point of view, it appears that the "functions are exported". This viewpoint is encouraged by the words in the Bash man page: "Functions may be exported so that subshells automatically have them defined with the -f option to the export builtin." ... and later ... "The supplied names are marked for automatic export to the environment of subsequently executed commands. If the -f option is given, the names refer to functions." I did mention "exported aliases or functions" in my original post, but I guess I should have said I was using -f. then dont use 'export -f' ... if you simply want it to be available in your shells, just declare it normally in say ~/.bashrc Yes, sure, thanks. I can sort out the world to my liking easily enough (and have been quite happy for the 2 years since this thread started. :-) However, I've learned something new today, and that is always useful. unless someone can point out an easy way to fix this, i'm going for a WONTFIX |