heh. brilliant. sorted it. TBC
Okay, seemingly the OOTB config does not have a ENV value defined
Ash honours this. and a strace confirms that it now reads /home/root/.bashrc
Setting ENV in a .bashrc has it's drawbacks as it will be processed twice.
So - more sensibly - we should probably just set the ENV value at boot to another filename and populate that with the current current .bashrc noise.
Anyways - that is by the by and will be decided in the wash.
Here are some tests.
[root@kindle root]#
echo $ENV
(nothing)
[root@kindle root]# su
[root@kindle root]#
grep -v
Quote:
|
BusyBox v1.7.2 (2011-09-08 21:57:14 PDT) multi-call binary
|
[root@kindle root]# exit
[root@kindle root]#
echo $ENV
/home/root/.bashrc
[root@kindle root]# su
[root@kindle root]#
grep -v
Quote:
|
BusyBox v1.20.2 (2012-09-03 02:06:04 BST) multi-call binary.
|
[root@kindle root]# exit
The ENV value is
NOT honored though when calling a single command as is shown here:
[root@kindle root]#
echo $ENV
(nothing)
[root@kindle root]#
su -c 'grep -v'
Quote:
|
BusyBox v1.7.2 (2011-09-08 21:57:14 PDT) multi-call binary
|
[root@kindle root]#
echo $ENV
/home/root/.bashrc
[root@kindle root]#
su -c 'grep -v'
Quote:
|
BusyBox v1.7.2 (2011-09-08 21:57:14 PDT) multi-call binary
|
which is worth noting now, for the future.
however explicitly informing it to use -l does work
[root@kindle root]#
su -c 'su -v' -l
su: invalid option -- v
Quote:
|
BusyBox v1.20.2 (2012-09-03 02:06:04 BST) multi-call binary.
|
So, this in mind - I'll go hunting down some use cases.
But ostensibly setting the
ENV value should do the trick, wherever it one day ends up being done.