simple pimple but i can't crach it , bash script 2

[tjbradford]

do
ps -a |grep desktop -c
if [[ $? -eq 0 ]] ; then
remotedesktopclient
sleep2
fi
done

I believe that the above should loop forever and if it sees apps that contain the word desktop in the ps -a list then it will show a value greater than one then after two seconds it will loop again.

if a user closes that app it will show a value of 0 and open the remotedesktopclient then pause there until it closes, again if closed will go back to the begining of this sentience , so why doesn't it work ?

it looks good to my tiny bit trained bash eye's

 

[tjbradford]

a value greater than one = a value greater than zero

sorry

 

[feherke]

Hi

I believe that the above should loop forever

No reason to loop there. Maybe using a [tt]while[/tt] :

[red]while :[/red]
do
[small]ps -a |grep desktop -c
if [[ $? -eq 0 ]] ; then
remotedesktopclient
sleep2
fi[/small]
done

it will show a value greater than one zero

Correct. It will show, meaning it will output it to standard output. But I see no reason in your code to output it, excepting debugging.

then after two seconds

Maybe if you have a command "sleep2". Otherwise :

[small]while :
do
ps -a |grep desktop -c
if [[ $? -eq 0 ]] ; then
remotedesktopclient[/small]
sleep[COLOR=red pink] [/color]2
[small]fi
done[/small]

if a user closes that app it will show a value of 0 and open the remotedesktopclient then pause there until it closes,

Incorrect. You are checking the previous command's exit code, not the value it output. And read the man page :

Normally, the exit status is 0 if selected lines are found and 1 otherwise.

So your conditional will evaluate to true if the [tt]grep[/tt] had found one or more processes with "desktop" in their command line.

Feherke.

http://rootshell.be/~feherke/

 

[felix001]

This should work...


ps -a | grep desktop -c
while [ $? -eq 0 ] ; do
remotedesktopclient
sleep 2
exit 0
else
exit 1
done

this would allow it to loop forever but you would need to add something to check to see if remote desktop is already running other wise you will just spawn endless remotedektop functions....

 

[feherke]

Hi

felix001, there you suggest to use
[ul]
[li]an [tt]else[/tt] keyword without [tt]if[/tt] .. [tt]fi[/tt][/li]
[li]a single [tt]ps[/tt] call although we need a fresh process list for each check[/li]
[li]a [tt]while[/tt] which will never execute more than once[/li]
[li][tt]exit[/tt] calls while nobody said the OP wants to exit the script in any circumstances[/li]
[/ul]
Sorry, but...

This should work...

...that will certainly never work. At least not in [tt]bash[/tt].

Feherke.

http://rootshell.be/~feherke/

 

[p5wizard]

ps -a | [red]grep desktop -c[/red]

???

ps -a | grep "[d]esktop"
if [ $? -eq 0 ]
then
echo "desktop process(es) found"
fi

num=$(ps -a |grep -c "[d]esktop")
if [ $num -gt 0 ]
then
echo "$num desktop processes found"
fi

Note: the grep RE "[d]esktop" instead of just "desktop" is to make sure that the grep process itself is not grepped from the ps output...



HTH,

p5wizard

 

[feherke]

Hi

Note: the grep RE "[d]esktop" instead of just "desktop" is to make sure that the grep process itself is not grepped from the ps output...

Correct. My brain skipped that because it finds the [tt]ps | grep[/tt] solution too ugly to process. (-: I prefer [tt]pgrep[/tt] or [tt]pidof[/tt].

As a curiosity, on Linux with [tt]ps -a[/tt] I not remember to ever hit that problem, only with [tt]ps aux[/tt].

Feherke.

http://rootshell.be/~feherke/

 

[p5wizard]

I was wondering about [tt]ps [red]-a[/red] | grep desktop[/tt] as well, but in any case [tt]ps -a | grep desktop -c[/tt] would simply complain about [tt]-c: no such file or directory[/tt] and not really [tt]grep[/tt] at all...


HTH,

p5wizard

 

[feherke]

Hi

in any case ps -a | grep desktop -c would simply complain about -c: no such file or directory and not really grep at all...

I expected such behavior, but GNU [tt]grep[/tt] accepts the parameters that way too.

While tjbradford uses [tt]bash[/tt], I assumed his [tt]grep[/tt] is also GNU, so I considered this only an ugliness and not mentioned it.

Feherke.

http://rootshell.be/~feherke/

 

[p5wizard]

So GNU grep doesn't even adhere to its own man page, or it is just a side effect?

I wouldn't count on that behaviour... Plus using it in scripts results in non-portable code!


HTH,

p5wizard

 

[feherke]

Hi

So GNU grep doesn't even adhere to its own man page, or it is just a side effect?

I would say, they forgive careless coding style. I do not agree with this and do not wish to promote such style. Is just not the first bad thing I used to point out when analyzing other people's code.

Feherke.

http://rootshell.be/~feherke/

 

[tjbradford]

ps -a | grep desktop -c
while [ $? -eq 0 ] ; do
remotedesktopclient
sleep 2
exit 0
else
sleep 5
done

this is pretty much what i did, it just continues and endless loop every time the rdp client is closed it opens it.

thanks for your help guys

 

[chipperMDW]

So GNU grep doesn't even adhere to its own man page, or it is just a side effect?

From the "Environment Variables" section of my GNU grep (2.5.3) man page:

       POSIXLY_CORRECT
              If set,  grep  behaves  as  POSIX.2  requires;  otherwise,  grep
              behaves  more  like  other  GNU programs.  POSIX.2 requires that
              options that follow file names must be treated as file names; by
              default,  such  options are permuted to the front of the operand
              list and are treated as options.  Also,  POSIX.2  requires  that
              unrecognized  options  be diagnosed as “illegal”, but since they
              are not really against the law the default is to  diagnose  them
              as      “invalid”.       POSIXLY_CORRECT      also      disables
              _N_GNU_nonoption_argv_flags_, described below.

The BNF used to specify command syntax in man pages is fairly loose. In particular, most GNU programs don't care about the order of options and non-option arguments; this is due in part to the fact that GNU libc's [tt]getopt[/tt] (and friends) are written to accept things in any order unless [tt]POSIXLY_CORRECT[/tt] is set.

 

[stefanwagner]

Instead of fiddeling with grep, you could use

ps -C remotedesktopclient

directly, to search for remotedesktopclient if this is what is meant.

pgrep desktop

might be helpful as well.


don't visit my homepage:

http://home.arcor.de/hirnstrom/minis/index.html

 

[p5wizard]

ps -C; pgrep; neither of these alternatives are available on every UNIX. So I'll just stick with what I know is portable:

[tt]ps -ef|grep [p]rocessname[/tt]


HTH,

p5wizard

 

[tjbradford]

agreed , pgrep is not common , compared with just grep which lets face it, is on almost all flavors