Ok in rxvt but not in script

[mikeb]

This works perfectly in rxvt but fails in a script.....it seems to get mixed up over spaces.

Code: Select all

ps | grep 'wget -c' | grep -v grep | sed 's%.*/\(.*\)http.*%\1%' >> /tmp/tart.status

line from ps...
9613 root 1404 S wget -c -o /tmp/tart.test -O /mnt/hda2/test.iso http://distro.ibiblio.org/pub/linux/distributions/puppy

expected result
test.iso
gives full line...breaking down the command truncation happens in the wrong places.

yet...

Code: Select all

	ps | grep 'cclive -c' | grep -v grep | sed 's%.*/\(.*\)http.*%\1%' >> /tmp/tart.status

working on
9684 root 1876 S cclive -c -f mp4 -O /mnt/hda2/test.mp4 http://www.youtube.com/watch?v=Sv5iEK-IEzw

gives expected
test.mp4

confused
mike

ok ..the eventual workaround was to turn around the wget commant to give
11061 root 1400 S wget -c -O /mnt/hda2/test.iso -o /tmp/tart.fhsgjsgfjs http://distro.ibiblio.org/pub/linux/distributions/pup
but I would like to know why there was a difference between the command line and script.

[amigo]

The output from ps, as with many other commands is formatted with TABs, so you need to grep for the line you need, then echo that and pipe through sed. The echo'ing converts tabs to spaces, eliminates duplicates and eliminates any leading or trailing spaces:
STATUS=$(ps | grep 'wget -c' | grep -v grep)
echo $STATUS | sed 's%.*/\(.*\)http.*%\1%' >> /tmp/tart.status

[mikeb]

Ah ok..thanks for the quick answer.
I tend to build up the command line to get the desired result then copy over to geany ...so basically I need to split apart to get consistant results .
I guess I've been running on luck rather than design

Ok I will implement (I don't like workarounds) and go forth

regards

mike

[mikeb]

Nope same behaviour...I will try on something else ...seems like a bash problem

mike

[Patriot]

Hmmm .....

mikeb,

Could it be that the ps shell script is causing this for you? ... I've always try to go direct to ps-FULL or busybox ps or when I'm sure of it, specify options, ie: ps ax ...


Rgds

[mikeb]

A possibility indeed...well I've got a meeting coming up Wednesday so I have to prepare including persuading some accounting software to install to a local web server...oh joy...so I will pick this one up in a while.
When I broke it down I would get results like
test.i or test.iso h at the end.
Something unpleasent from ps could be a possibility.

regards and a fun New Year

mike

[MinHundHettePerro]

Your sed-search-word "http" in most cases (with the reasonably short log- and output- file names you gave above) ends up around the truncation point of grep's. Try

Code: Select all

ps w

so as not to exclude your search-word. Doesn't explain your experienced difference between cli and script, though, unless there was an extra space or something ...

EDIT: Seems like (at least busybox 1.6.1) ps, without the wide-switch, only pipes 80 char's ...

fwiw /
MHHP

[mikeb]

Thanks for the input....I seem to be running on the busybox ps without any options....I will check behaviour with the full version.
Indeed I might take a different approach to tracking created processes anyway...
regards
mike

[Shel]

IIRC, the IRIX version of Unix includes a program called pgrep which reports whether a program is currently running. I stole that idea and implemented it as a shell script in Solaris, and it proved very handy. I'd give you the source, but all my Solaris machines are gone, and the tape archives of their contents are 8,000 miles away.

In general, though, it parsed the output of ps, as you're doing, and terminated with the appropriate exit code (and returned the job number[s] on stdout) if it found the program requested. As a stand-alone program, it could then be called by other programs to be sure I didn't run more than one copy of something, etc.

-Shel

[mikeb]

In general, though, it parsed the output of ps, as you're doing, and terminated with the appropriate exit code (and returned the job number[s] on stdout) if it found the program requested. As a stand-alone program, it could then be called by other programs to be sure I didn't run more than one copy of something, etc.

ooo that sounds better and it does seem it has been ported to linux....I do find this all a bit clumsy.....tracking processes when gtkdialog is used is a challenge and using text files is just plain messy...why have variables if everything has to be stored on the hard drive....ooo ranting again

mike

[Shel]

I do find this all a bit clumsy.....

The classical Unix programming philosophy is a bit different from what you might find in other systems; the emphasis is on small programs that do one thing well, and pass their output along is a way that makes them easy to use in various combinations. Typically, you then use all these little programs as "commands" in larger programs, which become "commands" in still larger programs, etc.

Once you have your "pgrep" program built, either as your own script or something ported from another system, you have it, and it becomes another building block. It's Lego for grownups.

-Shel

[mikeb]

It's Lego for grownups.

now that sounds more appealing.
I quite like using bash it was just this particular function that was a bit thorny.

Thanks for the input

mike

[Shel]

I decided to implement my own pgrep, and found that various ps commands act differently from the command line than from a script. It's a real WTF, but I think that's what started this whole thread!

In any case, here's what I'm using ...

Code: Select all

ps -e | grep " ${1}$" | grep -v ' grep ' | grep -v '<defunct>' | awk '{print $1}'

... all one one line.

I'm sure it could be done more elegantly, but this works, is reasonably fast, and finds the exact match.

The first grep finds the word given as the argument to the script, with a space in front and a newline after; the other two greps just get rid of stuff you don't want, while the awk prints the job number to stdout.

-Shel

[mikeb]

and found that various ps commands act differently from the command line than from a script.

so I was not going barmy then...oh too late
Well I'm free to play again with this cheers

mike

[amigo]

ps -e |grep "${1}$" | egrep -v '( grep |<defunct>)' | awk '{print $1}'

[big_bass]

Hey Gilbert

I played with grep and ps looking for a way to monitor services
for a little script I wrote to monitor cups
and I found another way of going at this


I tried to compile PSG but it failed but I liked the simple idea of it

so I found an alias instead that simulates it

Code: Select all

 alias psg='ps auxw | grep -v "grep -i" | grep -i --color'

then you just type

Code: Select all

psg cupsd

root 4561 0.0 0.1 4500 1584 ? Ss 19:07 0:00 /usr/sbin/cups



--------------------------------------


so I guess if wget was running

Code: Select all

psg wget 

psg wget
root 13181 0.5 0.1 3276 1336 pts/2 S+ 20:27 0:00 wget http://puppy2.org/slaxer/bluefish-1.0.7-i486-slxr.pet
#


add the filtering formatting you prefer
[/code]
nice and easy


Joe

[mikeb]

Hmm just thought of another approach to tracking and killing multiple spawned processes

Code: Select all

#make unique link to application
UNIQUE_ID="random string"
ln -s `which (binary)` /tmp/thing$UNIQUE_ID

#to run
/tmp/thing$UNIQUE_ID

#to monitor
[ `pidof thing$UNIQUE_ID` ]&& echo "It is still running"

#to kill....
kill `pidof thing$UNIQUE_ID`
rm /tmp/thing$UNIQUE_ID`

#or simply
killall thing$UNIQUE_ID

clean and simple, at least visually...probably a purists nightmare

mike

[mikeb]

Hey now here a kludge...rearranging only worked until there were spaces in the name.....I can tidy this up but would use the same method. I suspect the difference is to do with how multiple lines are handled in the terminal as apposed to a script

Code: Select all

function _status (){
	#stupid but what works in terminal will not work here so heres a bodge....
	ps | grep 'wget -c' | grep -v grep | sed 's%.*/\(.*\)-o.*%\1%' > /tmp/tart.status1
	ps | grep 'cclive -c' | grep -v grep | sed 's%.*/\(.*\)http.*%\1%' >> /tmp/tart.status1
	echo -e "\c" > /tmp/tart.status
	while read I ;do
	echo ${I##*/} >> /tmp/tart.status
	done < /tmp/tart.status1
}

I'm just assuming the first part of sed does not work reliably....all I wanted was to preserve the users readable name choice

mike

[sunburnt]

This sounds just like the script problem amigo and I were struggling with...

Bash interprets the arguments instead of passing them as literals.
There seems to be no way around this except to do it differently...