Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: bigpcman on May 23, 2010, 04:11:49 PM
-
I noticed when I hover over the opera wbar icon I get a black line to the right of it. There is nothing there when I'm not hovering. Probably nothing to do with tc3 but that's where I found it.
See attached pic.
tc@box:/usr/local$ cat tce.wbar
# The Bar && Font && Font size (11)
i: /usr/share/wbar/osxbarback.png
t: /usr/share/fonts/luxisr/11
c:
i: /usr/share/pixmaps/power.png
t: Exit
c: exec exittc
i: /usr/share/pixmaps/aterm.png
t: Aterm
c: exec aterm
i: /usr/share/pixmaps/cpanel.png
t: Panel
c: exec cpanel
i: /usr/share/pixmaps/appbrowser.png
t: Apps
c: exec appbrowser
i: /usr/local/share/pixmaps/opera10.png
t: Opera_browser-only
c: exec /usr/local/bin/opera -nomail -nolirc
tc@box:/usr/local$
tc@box:/usr/local/tce.installed$ ls
Xlibs_support mtd-2.6.33.3-tinycore
atk openssl-0.9.8
bash opera10
bzip2-lib pango
cairo pixman
dbus pycairo
dbus-glib pygobject
dbus-python pygtk
expat2 python
filesystems-2.6.33.3-tinycore qt-4.x-base
fontconfig shared-mime-info
glib2 sqlite3
graphics-libs-1 tcl_tk
gtk2 ttf-bitstream-vera
libcroco urwid
libffi wavemon
libglade wicd
libgsf wireless-2.6.33.3-tinycore
libiconv wireless_tools
librsvg wpa_supplicant
libxml2 x11vnc
-
[edit: unrelated in new thread]
@bigpcman: It's most likely a wbar related issue. I have seen something similar to it before with longer-than-icon text labels.
-
@bigpcman: It's most likely a wbar related issue. I have seen something similar to it before with longer-than-icon text labels.
You are right. I changed the wbar opera label to just opera and the black line went away.
-
Just curious why "wbar" is not executable?
tc@testbox:~/.X.d$ ls -al
total 4
drwxr-xr-x 2 tc staff 60 May 27 10:07 ./
drwxr-sr-x 6 tc staff 340 May 27 10:58 ../
-rw-r--r-- 1 tc staff 43 Apr 21 18:03 wbar
-
Just curious why "wbar" is not executable?
tc@testbox:~/.X.d$ ls -al
total 4
drwxr-xr-x 2 tc staff 60 May 27 10:07 ./
drwxr-sr-x 6 tc staff 340 May 27 10:58 ../
-rw-r--r-- 1 tc staff 43 Apr 21 18:03 wbar
As they are sourced, they don't need to be.
-
How do you restart wbar after boot. I tried "wbar.sh" but "echo $ICONS" reports nothing present. Wbar is running and all the standard icons are present.
Perhaps something else is wrong as well:
tc@testbox:~$ /usr/bin/wbar.sh
sh: wbar: unknown operand
and if I use brute force:
tc@testbox:/usr/bin$ sudo killall wbar
tc@testbox:/usr/bin$ wbar -bpress -config /usr/local/tce.wbar
tc@testbox:/usr/bin$ Couldn't open display
Edit: I made this mistake once before but forgot about it. I've been using ssh to communicate with my eeepc and that is what causes the "Couldn't open display" errors" and the problems with wbar.sh.
-
tc@testbox:~$ sudo wbar.sh
sh: wbar: unknown operand
tc@testbox:~$ wbar.sh
tc@testbox:~$ Xlib: extension "Generic Event Extension" missing on display ":0.0".
tc@testbox:~$
This seems curious too:
tc@testbox:~$ sudo -u tc wbar.sh
Sorry, user tc is not allowed to execute '/usr/bin/wbar.sh' as tc on testbox.
tc@testbox:~$
-
The script expects ICONS to be defined, but it will not be defined due to (default) sudo settings.
Typically, one might quote expected strings or similar to ensure one is evaluated.
-
If one wants to get more details of what is happening when a shell script gets executed one could run it with the '-vx' options. Those options have the following meaning:
-v verbose The shell writes its input to standard error as it is read.
-x xtrace Write each command to standard error (preceded by a '+ ') before it is executed.
(1) One should be certain which shell is meant to be used. This is specified in the so called "shebang" line (i.e. the first line of a script starting with '#!"):tc@box:~$ head -1 $( which wbar.sh )
#!/bin/shThat is not surprising since AFAIK all Core scripts are using '/bin/sh', but extensions are known to also use 'bash'.
(2) Now execute the script with the '-vx' option. Please note that 'sh' requires the full path to the script, hence the use of the command substitution with the 'which' command. If parameters are to be specified for the script they will have to follow outside of the command substitution (e.g. /bin/sh -vx $( which command ) param1 param2). tc@box:~$ sudo /bin/sh -vx $( which wbar.sh )
#!/bin/sh
cd "$HOME"
+ cd /home/tc
if [ $ICONS == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
[ -e .wbar ] && read OPTIONS < .wbar
wbar $OPTIONS -config /usr/local/tce.wbar >/dev/null &
fi
+ [ == wbar ]
sh: wbar: unknown operandLooking at the problem this way it's quite obvious: The '$ICONS' variable is undefined, and since it is not enclosed in double-quotes the shell produces the warning message.
For me personally as a rule of thumb I always try to enclose shell variables in double-quotes when used in comparisons. Albeit it's easy enough to forget, and warning messages are there to remind one of that.
Furthermore I believe that you were trying to use the wrong command: I'd use su -c COMMAND USER instead of sudo -u USER COMMAND. Therefore it would look like this:tc@box:~$ su -c "/bin/sh -vx $( which wbar.sh )" tc
#!/bin/sh
cd "$HOME"
+ cd /home/tc
if [ $ICONS == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
[ -e .wbar ] && read OPTIONS < .wbar
wbar $OPTIONS -config /usr/local/tce.wbar >/dev/null &
fi
+ [ wbar == wbar ]
+ pidof wbar
+ WBARPID=1490
+ [ -n 1490 ]
+ killall wbar
+ [ -e .wbar ]
+ read OPTIONS
tc@box:~$ + wbar -bpress -config /usr/local/tce.wbar
Xlib: extension "Generic Event Extension" missing on display ":0.0".
Now whether executing all those commands makes sense is not for me to judge. I was merely attemting to provide some advise of how I'd troubleshoot these sort of problems.
-
If one wants to get more details of what is happening when a shell script gets executed one could run it with the '-vx' options. Those options have the following meaning:
-v verbose The shell writes its input to standard error as it is read.
-x xtrace Write each command to standard error (preceded by a '+ ') before it is executed.
(1) One should be certain which shell is meant to be used. This is specified in the so called "shebang" line (i.e. the first line of a script starting with '#!"):tc@box:~$ head -1 $( which wbar.sh )
#!/bin/shThat is not surprising since AFAIK all Core scripts are using '/bin/sh', but extensions are known to also use 'bash'.
(2) Now execute the script with the '-vx' option. Please note that 'sh' requires the full path to the script, hence the use of the command substitution with the 'which' command. If parameters are to be specified for the script they will have to follow outside of the command substitution (e.g. /bin/sh -vx $( which command ) param1 param2). tc@box:~$ sudo /bin/sh -vx $( which wbar.sh )
#!/bin/sh
cd "$HOME"
+ cd /home/tc
if [ $ICONS == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
[ -e .wbar ] && read OPTIONS < .wbar
wbar $OPTIONS -config /usr/local/tce.wbar >/dev/null &
fi
+ [ == wbar ]
sh: wbar: unknown operandLooking at the problem this way it's quite obvious: The '$ICONS' variable is undefined, and since it is not enclosed in double-quotes the shell produces the warning message.
For me personally as a rule of thumb I always try to enclose shell variables in double-quotes when used in comparisons. Albeit it's easy enough to forget, and warning messages are there to remind one of that.
Furthermore I believe that you were trying to use the wrong command: I'd use su -c COMMAND USER instead of sudo -u USER COMMAND. Therefore it would look like this:tc@box:~$ su -c "/bin/sh -vx $( which wbar.sh )" tc
#!/bin/sh
cd "$HOME"
+ cd /home/tc
if [ $ICONS == wbar ]; then
WBARPID=$(pidof wbar)
[ -n "$WBARPID" ] && killall wbar
[ -e .wbar ] && read OPTIONS < .wbar
wbar $OPTIONS -config /usr/local/tce.wbar >/dev/null &
fi
+ [ wbar == wbar ]
+ pidof wbar
+ WBARPID=1490
+ [ -n 1490 ]
+ killall wbar
+ [ -e .wbar ]
+ read OPTIONS
tc@box:~$ + wbar -bpress -config /usr/local/tce.wbar
Xlib: extension "Generic Event Extension" missing on display ":0.0".
Now whether executing all those commands makes sense is not for me to judge. I was merely attemting to provide some advise of how I'd troubleshoot these sort of problems.
Thank you that was very informative.
-
sudo -u is a valid command, although the current sudo settings don't seem to allow it.
To try it change the setting to i.e. with visudo
tc ALL=(ALL) NOPASSWD: ALL
-
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
2.) using visudo made the "tc ALL=(ALL) NOPASSWD: ALL" change
reran sudo -u tc wbar.sh and received the
unknown operand error message.
BTW where is the ICON environment variable stored. I thought it was in /home/tc/.profile but I don't see it.
-
tc3alpha4
So to sum up, am I right in concluding there is no way to access the value (test value) while a root user either in the terminal or in a script, environment variables like:
$ICONS
$ENV
$BACKUP
$DESKTOP
since both
sudo -u tc ... and
su -c ... tc both fail to provide access.
-
I'm still not clear what you are trying to achieve by running something like su -c CMD tc but I think your system is "playing up".
The extracts I provided yesterday were from the same system that I've used to produced the following:tc@box:~$ version
tinycore_3.0alpha4
tc@box:~$ echo "ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP"
ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside
tc@box:~$ su -c "echo \"ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP\"" tc
ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside
tc@box:~$ sudo grep tc /etc/sudoers
tc ALL=(ALL) NOPASSWD: ALL
tc@box:~$ sudo -u tc echo "ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP"
ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside
If you don't get the same result try booting again with boot code "base norestore" to check your findings against a "plain" TC system.
Furthermore, ICONS is "controlled" by the following piece of code from '/etc/init.d/tc-config':ICONS="wbar"
TCEWBAR="/usr/local/tce.wbar"
if [ -z "$NOICONS" ] && [ -f /usr/share/wbar/dot.wbar ]; then
echo "$ICONS" > /etc/sysconfig/icons
fi
As you can see the setting is stored in '/etc/sysconfig/icons' and is taken from there on occasion by other scripts.
Please note that '/etc/sysconfig/icons' contains pretty much all stuff related to boot codes and initial system setup. I highly recommend to grab yourself a cup of tea (or whatever else) and study this file and it's inter-working with other scripts really carefully. Since the shell under which all this gets executed has only fairly sparse documentation (http://busybox.net/downloads/BusyBox.html) I'd suggest to use this one here (http://linux.die.net/man/1/ash) instead.
I'm afraid this is all getting a bit off-topic (you might want to ask hats to split this thread) ...
-
I'm still not clear what you are trying to achieve by running something like su -c CMD tc but I think your system is "playing up".
The extracts I provided yesterday were from the same system that I've used to produced the following:tc@box:~$ version
tinycore_3.0alpha4
tc@box:~$ echo "ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP"
ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside
tc@box:~$ su -c "echo \"ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP\"" tc
ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside
tc@box:~$ sudo grep tc /etc/sudoers
tc ALL=(ALL) NOPASSWD: ALL
tc@box:~$ sudo -u tc echo "ICONS=$ICONS ENV=$ENV BACKUP=$BACKUP DESKTOP=$DESKTOP"
ICONS=wbar ENV=/home/tc/.ashrc BACKUP=1 DESKTOP=flwm_topside
If you don't get the same result try booting again with boot code "base norestore" to check your findings against a "plain" TC system.
Furthermore, ICONS is "controlled" by the following piece of code from '/etc/init.d/tc-config':ICONS="wbar"
TCEWBAR="/usr/local/tce.wbar"
if [ -z "$NOICONS" ] && [ -f /usr/share/wbar/dot.wbar ]; then
echo "$ICONS" > /etc/sysconfig/icons
fi
As you can see the setting is stored in '/etc/sysconfig/icons' and is taken from there on occasion by other scripts.
Please note that '/etc/sysconfig/icons' contains pretty much all stuff related to boot codes and initial system setup. I highly recommend to grab yourself a cup of tea (or whatever else) and study this file and it's inter-working with other scripts really carefully. Since the shell under which all this gets executed has only fairly sparse documentation (http://busybox.net/downloads/BusyBox.html) I'd suggest to use this one here (http://linux.die.net/man/1/ash) instead.
I'm afraid this is all getting a bit off-topic (you might want to ask hats to split this thread) ...
Maro you are a wealth of information. Thank you for providing your advice.
Here's what I get in the console as root user:
root@testbox:/home/tc# echo $ICONS
root@testbox:/home/tc# sudo -u tc echo $ICONS
root@testbox:/home/tc# su -c echo $ICONS tc
root@testbox:/home/tc#
tc@testbox:~$ echo $ICONS
wbar
tc@testbox:~$
edit: tc3alpha4 iso base norestore with sudoers modified to [tc ALL=(ALL) NOPASSWD: ALL]
edit2: I just noticed I should have been using the double quotes in the "su" command as follows: su -c "echo $ICONS" tc
However, the results are the same.
-
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.
-
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.
-
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):
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.
-
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!
-
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
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.
-
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 (http://forum.tinycorelinux.net/index.php?topic=5942.0).
-
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"? :)
-
Stream EDitor :)