Several of the system scripts, for example, /sbin/depscan.sh, assume that the commands cp, ls, mv, rm etc. are the standard ones in /bin. The scripts do set up an approprate PATH, I think, but don't get rid of any exported aliases or functions. The scripts don't work if you have configured these commands as aliases or Bash functions. For example, I normally make rm equivalent to "rm -i" and ls equivalent to "ls -F". Having done this, I find that "sudo /sbin/depscan.sh" no longer works. I also get rm prompts during emerge operations. There are ways round this, of course, which is why I've set the severity to minor, but it is a bit of a gotcha for newcomers.
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
