wbar (and X.d) questions

[^thehatsrule^]

tc3alph4
Progress report

1.) su -c "/bin/sh -vx $( which wbar.sh )" tc

and

su -c wbar.sh tc

returns:

su: must be suid to work properly

busybox should be setuid, unless you have changed it yourself.

2.) using visudo made the "tc   ALL=(ALL) NOPASSWD: ALL" change

reran sudo -u tc wbar.sh and received the
unknown operand error message.

This is expected, as hinted in

The script expects ICONS to be defined, but it will not be defined due to (default) sudo settings.

If you want to change this, refer to documentation on the sudo commandline options or the sudoers file.  However, su does pass down the environment iirc.

@maro: those don't really apply, as variable substitution will occur in the current shell before execution.

The P&S section may be more appropriate if this continues.

[bigpcman]

tc3alph4
Progress report

1.) su -c "/bin/sh -vx $( which wbar.sh )" tc

and

su -c wbar.sh tc

returns:

su: must be suid to work properly

busybox should be setuid, unless you have changed it yourself.

2.) using visudo made the "tc   ALL=(ALL) NOPASSWD: ALL" change

reran sudo -u tc wbar.sh and received the
unknown operand error message.

This is expected, as hinted in

The script expects ICONS to be defined, but it will not be defined due to (default) sudo settings.

If you want to change this, refer to documentation on the sudo commandline options or the sudoers file.  However, su does pass down the environment iirc.

@maro: those don't really apply, as variable substitution will occur in the current shell before execution.

The P&S section may be more appropriate if this continues.

For me this whole subject got started because I could not get wbar.sh to execute when called from a script that used "sudo',  ie "sudo myscript"
This used to work fine going back to tc2.2 so I  investigated what changed regarding "wbar.sh" .  It boils down to this:

old wbar.sh

if [ $(cat etc/sysconfig/icons) == wbar]; then

vs the current wbar.sh

if [$ICONS ==]; then

There you have it.  As I understand it, one way it works for all users including root the other only for user tc. Maybe there is a very good reason for the change but I would prefer it to be the way it was.

[maro]

Hats has raised an important point (which I'd come across myself in the mean time): Due to the use of double-quotes the current shell (of user 'tc') evaluates the variables first, before it "hands over" the results to the 'echo' command. But I believe the following shows that using single-quotes eliminates this effect (I've made a small amendment to show which process does the variable evaluation):

Code: [Select]

tc@box:~$ echo "PID=$$" ; su -c "echo \"PID=$$ ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP\"" tc
PID=1152
PID=1152 ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside

tc@box:~$ echo "PID=$$" ; su -c 'echo PID=$$ ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP' tc   
PID=1152
PID=11010 ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside

So that aside back to the original difference between what I was doing and what bigpcman did: He was not completely "honest" with us by not telling us that those commands were run from a shell started with sudo sh. Only the root@testbox:/home/tc# prompt revealed that fact, but was unknown until reply #14. There are obviously differences in the environments of a shell run by user 'tc' and one started with sudo sh or sudo su. This becomes clear when comparing the output of the commands env and set in each of those shells. Please note that sudo su operates in the 'root' user home directory which is '/root'.

Likewise if one would check the initial shell from which the X server was started from (e.g. using the key combination of "Ctrl-Alt-F1") one would find that this shell has also no ICONS defined. Any shell started from within the GUI will have the variable defined, as the variable was presumably set (and exported) by the execution of startx.

Finally, I tend to agree that that the "old way" of using '/etc/sysconfig/icons' as the source of the information looks "safe", compared to relying on the variable inheritance between processes.

[bigpcman]

Finally, I tend to agree that that the "old way" of using '/etc/sysconfig/icons' as the source of the information looks "safe", compared to relying on the variable inheritance between processes.

Crap! Nothing is as simple as it seems. By using '/etc/sysconfig/icons' in "wbar.sh" thereby allowing root user scripts to call wbar.sh the result is that the wbar process is created and then owned by root instead of tc. If I'm not mistaken there may be other "tc user" scripts that perform "killall wbar" or some other action which of course won't work. I don't know for sure one way or another.

I started down this rat hole because it appears that the "services" panel tool calls the init.d scripts as a root user and I happen to have a call to wbar.sh in the vnc service script.

I guess I'll have to go with a custom wbar restart script that uses  '/etc/sysconfig/icons' for the icons test and "su -c 'wbar ...' tc" if the user is not tc. Yikes!

[Lee]

re. the original post in this thread...

In the listing of /usr/local/tce.wbar - you can adjust the font size given in the first line beginning with "t:".  You probably don't want to back up your tce.wbar so I have a script that handles this for me.  The pertinent snippet from that script is

Code: [Select]

WBAR=/usr/local/tce.wbar

WLINES=`wc -l ${WBAR} |cut -d" " -f1`
cp ${WBAR} ~/tce.wbar.orig

head -2 ~/tce.wbar.orig >${WBAR}

echo "t: /usr/share/fonts/luxisr/7" >>${WBAR}

WLINES=`expr ${WLINES} \- 3`
tail -${WLINES} ~/tce.wbar.orig >>${WBAR}


which replaces the entire line, setting the font size to 7 instead of 11.

[maro]

Lee: Whilst I trust that your code snippet works for you I wonder whether you have considered to use a single 'sed' command instead.

I believe sudo sed -i 's#/usr/share/fonts/luxisr/11#/usr/share/fonts/luxisr/7#' /usr/local/tce.wbar achieves the same. Now there are many ways to save on the keystrokes, e.g. sudo sed -i '3s#/11$#/7#' /usr/local/tce.wbar limits the change just to the third line of the file and is therefore closer to your approach.

It's quite a lot what one can do with the humble 'sed'. A few links for further reading are mentioned here.

[Lee]

Thanks for the tip Maro.

It has been on my "to do" list for a long time to learn  how to use sed... but I haven't done so yet.   

My code snippet does the job nicely on MC 2.11 but something (and this is the most likely suspect) failed miserably on MC 2.11.2 and I got no wbar at all (MC 2.11/2.11.2 with core elements, jwm and wbar).  I haven't had time to debug that yet.  A more robust solution, perhaps involving sed, is certainly in order.

"sed"... that's short for "sedition"? 

[curaga]

Stream EDitor