Re: function invoking alias fails if defined in same conditional
On 03/16/2012 02:56 PM, gregrwm wrote: > a function invoking an alias works, unless they are defined within the same > conditional, eg: Thanks for the report, but this is not a bug. Remember, aliases affect parsing, so they can only be expanded during the parsing phase. But bash has to parse until the end of a compound command before it can do any action within the command. In that sense, 'alias' is exactly like 'set -v' just recently discussed here: https://lists.gnu.org/archive/html/help-bash/2012-03/msg00025.html > > $ if true;then >>alias aseparate='echo aseparate' >> fi > $ if true;then >> fseparate()(aseparate) >> fi Bash parsed two commands, so the parse of the second command was done with the alias expansion of the first command in effect. > $ if true;then >>alias atogether='echo atogether' >> ftogether()(atogether) >> fi Here, bash parses the entire compound command, then starts executing it. At the time of the parse, ftogether() was declared without any extra meaning for atogether. > $ aseparate > aseparate > $ fseparate > aseparate > $ atogether > atogether > $ ftogether > bash: atogether: command not found This behavior is expected, and not a bug. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: function invoking alias fails if defined in same conditional
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/17/12 8:09 AM, Eric Blake wrote: > On 03/16/2012 02:56 PM, gregrwm wrote: >> a function invoking an alias works, unless they are defined within the same >> conditional, eg: > > Thanks for the report, but this is not a bug. Remember, aliases affect > parsing, so they can only be expanded during the parsing phase. But > bash has to parse until the end of a compound command before it can do > any action within the command. In that sense, 'alias' is exactly like > 'set -v' just recently discussed here: > https://lists.gnu.org/archive/html/help-bash/2012-03/msg00025.html The manual page has this to say: "To be safe, always put alias definitions on a separate line, and do not use alias in com- pound commands." Chet - -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9kuN8ACgkQu1hp8GTqdKsWBwCeMKkybgdM31sig8O6aVv62cPd W6IAn3yAKnmTfhwo8S1VW1Z63i/PmgwT =PVXT -END PGP SIGNATURE-
Re: function invoking alias fails if defined in same conditional
e&c- thanks for clarifying. -g "No culture can live, if it attempts to be exclusive." —*Gandhi*
Re: Saving command history for non-interactive shell
Am 16.03.2012 15:56, schrieb Greg Wooledge:
On Fri, Mar 16, 2012 at 02:33:35PM +, Lars Peterson wrote:
Is there a way to configure bash so that commands from a non-interactive
shell are preserved in the history? I'm more interested in saving commands
invoked via ssh vs shell scrpts.
From CHANGES, for bash 4.1:
l. There is a new configuration option (in config-top.h) that forces bash to
forward all history entries to syslog.
However, that only applies to commands that bash is already adding to
its history. So you'd also have to do a "set -o history" command at
some point, since non-interactive shells don't do that by default.
That might be tricky to arrange.
And of course you'd have to force the ssh user to use your specially
compiled bash with the SYSLOG_HISTORY option, and not some other shell.
If the larger context is "I want to know everything my users are doing",
you're going to end up frustrated. Unix simply wasn't designed to lock
users down. Quite the opposite -- it was designed to give users full
power. Users can make system calls without going through a shell, by
writing C code and so on. They can also invoke processes without using
a shell, if processes are the thing you actually want to track, rather
than, for instance, file system operations.
If any of the above resembles your actual goal, then you need to look
into "accounting" ("process accounting", etc.). It's a huge topic, and
logging shell commands doesn't even come close to addressing it.
Just a suggestion but if its only about ssh then you could chroot to a
new base and replace the bash with a bash script.
or change the default shell. to something like this.
file
/bin/bash
#!/bin/realbash
exec /bin/realbash -o history "${@}"
i.e. so that when bash is called you enable history. haven't really
tried it but I think it should be possible.
or do something like
/bin/bash
#!/bin/realbash
exec logapp /bin/realbash -o xtrace "${@}"
/bin/logbash
#!/bin/bash
exec logapp /bin/bash -o xtrace "${@}"
testsctipt.sh
#!/bin/logbash
do something here .
just some rough ideas.
I mean depending on your setup you could either change the account
default shell, only allow execution of the special logging shell, or
just specify the logging shell in you hash bang entry.
heck you could even do something really crazy like manually read the
bash input/script usinf read and eval each line of code,
something like
while read -re ; do
echo "${REPLY}"
eval "${REPLY}" ## not saying its a good idea just that there are a
lot of ways to skin this particular fish.
done
or even something like
/bin/logscript
#!/bin/bash
trap 'echo "${BASH_COMMAND}" >> Logfile' DEBUG
source "${1}"
Re: Saving command history for non-interactive shell
Am 17.03.2012 22:10, schrieb dethrophes:
Am 16.03.2012 15:56, schrieb Greg Wooledge:
On Fri, Mar 16, 2012 at 02:33:35PM +, Lars Peterson wrote:
Is there a way to configure bash so that commands from a
non-interactive
shell are preserved in the history? I'm more interested in saving
commands
invoked via ssh vs shell scrpts.
From CHANGES, for bash 4.1:
l. There is a new configuration option (in config-top.h) that forces
bash to
forward all history entries to syslog.
However, that only applies to commands that bash is already adding to
its history. So you'd also have to do a "set -o history" command at
some point, since non-interactive shells don't do that by default.
That might be tricky to arrange.
And of course you'd have to force the ssh user to use your specially
compiled bash with the SYSLOG_HISTORY option, and not some other shell.
If the larger context is "I want to know everything my users are doing",
you're going to end up frustrated. Unix simply wasn't designed to lock
users down. Quite the opposite -- it was designed to give users full
power. Users can make system calls without going through a shell, by
writing C code and so on. They can also invoke processes without using
a shell, if processes are the thing you actually want to track, rather
than, for instance, file system operations.
If any of the above resembles your actual goal, then you need to look
into "accounting" ("process accounting", etc.). It's a huge topic, and
logging shell commands doesn't even come close to addressing it.
Just a suggestion but if its only about ssh then you could chroot to a
new base and replace the bash with a bash script.
or change the default shell. to something like this.
file
/bin/bash
#!/bin/realbash
exec /bin/realbash -o history "${@}"
i.e. so that when bash is called you enable history. haven't really
tried it but I think it should be possible.
or do something like
/bin/bash
#!/bin/realbash
exec logapp /bin/realbash -o xtrace "${@}"
/bin/logbash
#!/bin/bash
exec logapp /bin/bash -o xtrace "${@}"
testsctipt.sh
#!/bin/logbash
do something here .
just some rough ideas.
I mean depending on your setup you could either change the account
default shell, only allow execution of the special logging shell, or
just specify the logging shell in you hash bang entry.
heck you could even do something really crazy like manually read the
bash input/script usinf read and eval each line of code,
something like
while read -re ; do
echo "${REPLY}"
eval "${REPLY}" ## not saying its a good idea just that there are a
lot of ways to skin this particular fish.
done
or even something like
/bin/logscript
#!/bin/bash
trap 'echo "${BASH_COMMAND}" >> Logfile' DEBUG
source "${1}"
though if they are your scripts youd be better of doing it differently.
I do this
sRunProg cmd "arg 1" "arg 2" "arg 3"
sErrorOut "message line 1" "message line 2"
sLogOut "message line 1" "message line 2"
sDebugOut "message line 1" "message line 2"
which gives me log files like this
"rm" "--interactive=never"
"/mnt/DETH00/media/New/New.Folder/sigs.sha256" #C: Wed Feb 15 23:32:11
CET 2012 : 18336 : CoreFuncs.sh(87 ) : SimpleDelFile :
"ln" "--symbolic" "/mnt/DETH00/media/file1"
"/mnt/DETH00/media/New/New.Folder/file1" #C: Wed Feb 15 23:32:11 CET
2012 : 18336 : move.sh (255 ) : Move_int:
#L: Fri Feb 17 14:31:13 CET 2012 : 8262 : SortFiles.sh(135 ) :
main: "/home/dethrophes/scripts/bash/SortFiles.sh"
"--SupportedOptions"
so I can actually source the log file as a bash script if I want to ,
furthermore the if the output is to the console I colorize the
errors/command etc.
and errors get logged, output to the console in red and if gui mode
enables sent to the x notify system, and a function call trace gets
logged as well.
#D: Fri Jan 13 13:22:03 CET 2012 : 7319 : LogFuncs.sh (46 ) :
main: "[4]/home/dethrophes/scripts/bash/GenFuncs.sh(46):source"
#D: Fri Jan 13 13:22:03 CET 2012 : 7319 : GenFuncs.sh (484 ) :
source :
"[3]/home/dethrophes/scripts/bash/GenFuncs.sh(484):CleanRevision"
#D: Fri Jan 13 13:22:03 CET 2012 : 7319 : GenFuncs.sh (131 ) :
CleanRevision :
"[2]/home/dethrophes/scripts/bash/GenFuncs.sh(131):ReturnString"
#D: Fri Jan 13 13:22:03 CET 2012 : 7319 : GenFuncs.sh (127 ) :
ReturnString:
"[1]/home/dethrophes/scripts/bash/LogFuncs.sh(127):TaceEvent"
#E: Fri Jan 13 13:22:03 CET 2012 : 7319 : GenFuncs.sh (127 ) :
ReturnString: "RETURN
/home/dethrophes/scripts/bash/LogFuncs.sh(127):ReturnString ELEVEL=0
\"echo \"\${@}\
I find this approach easier to work with.
most of this is done in
https://github.com/dethrophes/Experimental-Bash-Module-System/blob/master/bash/LogFuncs.sh
if it is of interest.
