...making Linux just a little more fun!
J. Bakshi [j.bakshi at unlimitedmail.org]
Hello,
I have a working configuration at .icewm/toolbar to take screen shot
---------------------------------------- prog "screenshot" /usr/share/pixmaps/khelpcenter-16.xpm scrot -s -q 100 -e 'feh $f' ------------------------------------------------
I have put the same configuration in a shell script and it also has the u+x permission. I manually executed it and it worked as expected. Now I have create a rule in .icewm/keys like
--------------------------------- # Super is the microsoft key at key board key "Super+g" grun key "Super+Power" gmrun key "Super+s" /home/joy/call ----------------------------------
But this time it is not working any more. Though the configuration from toolbar as well as the script is working well. My other key combination is also working well except the above screenshot. What might be the problem here ?
Thanks
PS: Kindly CC me
Ben Okopnik [ben at linuxgazette.net]
On Sat, Apr 04, 2009 at 12:19:45PM +0530, J. Bakshi wrote:
> Hello, > > I have a working configuration at .icewm/toolbar to take screen shot > > ---------------------------------------- > prog "screenshot" /usr/share/pixmaps/khelpcenter-16.xpm scrot -s -q > 100 -e 'feh $f' > ------------------------------------------------
Presumably, that's all on one line. It certainly should be.
> I have put the same configuration in a shell script and it also has the > u+x permission. I manually executed it and it worked as expected. Now I > have create a rule in .icewm/keys like > > --------------------------------- > # Super is the microsoft key at key board > > key "Super+g" grun > key "Super+Power" gmrun > key "Super+s" /home/joy/call > ---------------------------------- > > But this time it is not working any more. Though the configuration from > toolbar as well as the script is working well. My other key combination > is also working well except the above screenshot. What might be the > problem here ?
Good question. Does the "Super+s" combination actually work? Try it with a program that'll definitely run - e.g., "xeyes". In the past, I've also found that some hot-key systems (not the one in IceWM - this was in GNOME) will not run a script that doesn't have a shebang at the top. You might want to try that, just in case.
Also, just as a general principle, you shouldn't scatter your scripts all over the place - you'll never remember where to find them later. I suggest you create a "/home/joy/bin" subdirectory, add it to your PATH, and place your scripts in there. Anything that you want to make available to all the users on your system (assuming that you have root access) should go into /usr/local/bin.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Thomas Adam [thomas.adam22 at gmail.com]
2009/4/4 Ben Okopnik <ben@linuxgazette.net>:
> On Sat, Apr 04, 2009 at 12:19:45PM +0530, J. Bakshi wrote: >> Hello, >> >> I have a working configuration at .icewm/toolbar to take screen shot >> >> ---------------------------------------- >> prog "screenshot" /usr/share/pixmaps/khelpcenter-16.xpm scrot -s -q >> 100 -e 'feh $f' >> ------------------------------------------------ > > Presumably, that's all on one line. It certainly should be. > >> I have put the same configuration in a shell script and it also has the >> u+x permission. I manually executed it and it worked as expected. Now I >> have create a rule in .icewm/keys like >> >> --------------------------------- >> # Super is the microsoft key at key board >> >> key "Super+g" grun >> key "Super+Power" gmrun >> key "Super+s" /home/joy/call >> ---------------------------------- >> >> But this time it is not working any more. Though the configuration from >> toolbar as well as the script is working well. My other key combination >> is also working well except the above screenshot. What might be the >> problem here ? > > Good question. Does the "Super+s" combination actually work? Try it with > a program that'll definitely run - e.g., "xeyes". In the past, I've also > found that some hot-key systems (not the one in IceWM - this was in > GNOME) will not run a script that doesn't have a shebang at the top. You > might want to try that, just in case.
The way to debug this is to post the output of:
xmodmap -pm
And to then use "xev" to determining what the key combinations are.
-- Thomas Adam
J. Bakshi [j.bakshi at unlimitedmail.org]
On Sat, 4 Apr 2009 17:34:45 +0100 Thomas Adam <thomas.adam22@gmail.com> wrote:
> The way to debug this is to post the output of: > > `` > xmodmap -pm > '' > > And to then use "xev" to determining what the key combinations are.
Fantastic tip, It will help me know how the special keys are represented.
Thanks a lot
J. Bakshi [j.bakshi at unlimitedmail.org]
On Sat, 4 Apr 2009 10:05:04 -0400 Ben Okopnik <ben@linuxgazette.net> wrote:
> On Sat, Apr 04, 2009 at 12:19:45PM +0530, J. Bakshi wrote: > > Hello, > > > > I have a working configuration at .icewm/toolbar to take screen shot > > > > ---------------------------------------- > > prog "screenshot" /usr/share/pixmaps/khelpcenter-16.xpm scrot -s -q > > 100 -e 'feh $f' > > ------------------------------------------------ > > Presumably, that's all on one line. It certainly should be.
Yes it is in one line in my script
> > > I have put the same configuration in a shell script and it also has > > the u+x permission. I manually executed it and it worked as > > expected. Now I have create a rule in .icewm/keys like > > > > --------------------------------- > > # Super is the microsoft key at key board > > > > key "Super+g" grun > > key "Super+Power" gmrun > > key "Super+s" /home/joy/call > > ---------------------------------- > > > > But this time it is not working any more. Though the configuration > > from toolbar as well as the script is working well. My other key > > combination is also working well except the above screenshot. What > > might be the problem here ? > > Good question. Does the "Super+s" combination actually work? Try it > with a program that'll definitely run - e.g., "xeyes". In the past, > I've also found that some hot-key systems (not the one in IceWM - > this was in GNOME) will not run a script that doesn't have a shebang > at the top. You might want to try that, just in case.
yes the combination is working as I already tested it with aterm like key "Super+s" aterm
> > Also, just as a general principle, you shouldn't scatter your scripts > all over the place - you'll never remember where to find them later. I > suggest you create a "/home/joy/bin" subdirectory, add it to your > PATH, and place your scripts in there. Anything that you want to make > available to all the users on your system (assuming that you have root > access) should go into /usr/local/bin.
Thanks. I have already implemented as per your suggestion i.e. I have moved all my script in bin folder under my home folder. I have also put "#! /bin/bash " at the top of my script but no success yet. Interestingly if I modified my script like
key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'"
I can see that aterm appears just for a moment and then disappears. So the key combination successfully call the aterm but for an unknown reason the rest part is not executed.
I have no clue to this problem
J. Bakshi [j.bakshi at unlimitedmail.org]
On Sun, 5 Apr 2009 12:47:40 +0530 "J. Bakshi" <j.bakshi@unlimitedmail.org> wrote:
> Thanks. I have already implemented as per your suggestion i.e. I have > moved all my script in bin folder under my home folder. I have also > put "#! /bin/bash " at the top of my script but no success yet. > Interestingly if I modified my script like > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'"
sorry for the type mistake
it is
key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'
I added an extra " before during type.
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 12:47:40PM +0530, J. Bakshi wrote:
> > Thanks. I have already implemented as per your suggestion i.e. I have > moved all my script in bin folder under my home folder. I have also > put "#! /bin/bash " at the top of my script but no success yet. > Interestingly if I modified my script like > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'"
Ah - I've just spotted your problem. You've got an extra double-quote at the end of the line.
> I can see that aterm appears just for a moment and then disappears. So > the key combination successfully call the aterm but for an unknown > reason the rest part is not executed.
It sounds like it is executed, but exits immediately - which would make 'aterm' exit as well.
For future reference, here's a tool I use to troubleshoot "xterm -e"-type interactions:
echo -e \#\!"`which bash`\n\$@\nread" > ~/bin/hold; chmod +x bin/hold
This will create a script called 'hold', which will stop your 'aterm -e' from exiting, so you can see the error. To troubleshoot, run your program like this:
aterm -e hold scrot -s -q 100 -e 'feh $f'
This will exec scrot, but leave the terminal open so you can see what failed.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 01:07:34PM +0530, J. Bakshi wrote:
> > > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'" > > sorry for the type mistake > > it is > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f' > > I added an extra " before during type.
Well, that's why I added the other explanation as well.
Joydeep, you need to make sure that you always COPY AND PASTE errors - don't ever retype them. In the absolutely worst case - e.g., errors during boot, when there's no way to copy them - use a digital camera, post the image somewhere, and give us a link. But don't ever retype errors. If you miss so much as a character, you'll lead everyone down the wrong path - and you really don't want to annoy the people who are helping you.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Thomas Adam [thomas.adam22 at gmail.com]
2009/4/5 Ben Okopnik <ben@linuxgazette.net>:
> On Sun, Apr 05, 2009 at 12:47:40PM +0530, J. Bakshi wrote: >> >> Thanks. I have already implemented as per your suggestion i.e. I have >> moved all my script in bin folder under my home folder. I have also >> put "#! /bin/bash " at the top of my script but no success yet. >> Interestingly if I modified my script like >> >> key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'" > > Ah - I've just spotted your problem. You've got an extra double-quote at > the end of the line. > >> I can see that aterm appears just for a moment and then disappears. So >> the key combination successfully call the aterm but for an unknown >> reason the rest part is not executed. > > It sounds like it is executed, but exits immediately - which would > make 'aterm' exit as well. > > For future reference, here's a tool I use to troubleshoot "xterm > -e"-type interactions: > > `` > echo -e \#\!"`which bash`\n\$@\nread" > ~/bin/hold; chmod +x bin/hold > ''
Nice. I tend to prefer:
xterm -hold -e some_command
Not generaly portable for all terminal emulators, but most of them (rxvt{,unicode}, xterm, etc) has such an option.
-- Thomas Adam
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 01:57:57PM +0100, Thomas Adam wrote:
> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>:
> >
> > For future reference, here's a tool I use to troubleshoot "xterm
> > -e"-type interactions:
> >
> > ``
> > echo -e \#\!"`which bash`\n\$@\nread" > ~/bin/hold; chmod +x bin/hold
> > ''
>
> Nice. I tend to prefer:
>
> ``
> xterm -hold -e some_command
> ''
>
> Not generaly portable for all terminal emulators, but most of them
> (rxvt{,unicode}, xterm, etc) has such an option.
Yeah, portability is exactly why I use the script. It's useful to know about '-hold' as well, though.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
J. Bakshi [j.bakshi at unlimitedmail.org]
On Sun, 5 Apr 2009 08:50:35 -0400 Ben Okopnik <ben@linuxgazette.net> wrote:
> On Sun, Apr 05, 2009 at 01:07:34PM +0530, J. Bakshi wrote: > > > > > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'" > > > > sorry for the type mistake > > > > it is > > > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f' > > > > I added an extra " before during type. > > Well, that's why I added the other explanation as well. > > Joydeep, you need to make sure that you always COPY AND PASTE errors - > don't ever retype them. In the absolutely worst case - e.g., errors > during boot, when there's no way to copy them - use a digital camera, > post the image somewhere, and give us a link. But don't ever retype > errors. If you miss so much as a character, you'll lead everyone down > the wrong path - and you really don't want to annoy the people who > are helping you. > >
I admit, I am really sorry for that. I'll also check the hints you have suggested and coming back with the feedback. Once again I'm really sorry for the typing error
J. Bakshi [j.bakshi at unlimitedmail.org]
On Sun, 5 Apr 2009 08:44:22 -0400 Ben Okopnik <ben@linuxgazette.net> wrote:
> On Sun, Apr 05, 2009 at 12:47:40PM +0530, J. Bakshi wrote: > > > > Thanks. I have already implemented as per your suggestion i.e. I > > have moved all my script in bin folder under my home folder. I have > > also put "#! /bin/bash " at the top of my script but no success yet. > > Interestingly if I modified my script like > > > > key "Super+s" aterm -e scrot -s -q 100 -e 'feh $f'" > > Ah - I've just spotted your problem. You've got an extra double-quote > at the end of the line. > > > I can see that aterm appears just for a moment and then disappears. > > So the key combination successfully call the aterm but for an > > unknown reason the rest part is not executed. > > It sounds like it is executed, but exits immediately - which would > make 'aterm' exit as well. > > For future reference, here's a tool I use to troubleshoot "xterm > -e"-type interactions: > > `` > echo -e \#\!"`which bash`\n\$@\nread" > ~/bin/hold; chmod +x bin/hold > '' > > This will create a script called 'hold', which will stop your 'aterm > -e' from exiting, so you can see the error. To troubleshoot, run your > program like this: > > ``` > aterm -e hold scrot -s -q 100 -e 'feh $f' > ''' > > This will exec scrot, but leave the terminal open so you can see what > failed. > >
Thanks for the debugger. It will also help me to debug other command too. It has helped me to catch the error.
First of all I created "hold" script as you shown above. Then I executed the actual command as
joy@debian:~/bin$ aterm -e ~/bin/hold scrot -s -q 100 -e 'feh $f'
and bingo !! aterm is in holding stage. It allow me to take the sceenshot but after that the error is
giblib error: Saving to file failed
If I delete the feh part ( so it is only aterm -e ./hold scrot -s -q 100 ) there is no error message and there is also a image as "2009-04-05-214611_286x257_scrot.png"
Though the command
scrot -s -q 100 -e 'feh $f'
works fine. I am really confused why it is not working with key combination ( but with toolbar ) and why the error message when executing with aterm -e !!
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 10:08:59PM +0530, J. Bakshi wrote:
> > Thanks for the debugger. It will also help me to debug other command too. > It has helped me to catch the error.
Good! I'm glad that got you further along.
> First of all I created "hold" script as you shown above. Then I > executed the actual command as > > ``` > joy@debian:~/bin$ aterm -e ~/bin/hold scrot -s -q 100 -e 'feh $f' > ''' > > and bingo !! aterm is in holding stage. It allow me to take the > sceenshot but after that the error is > > ``` > giblib error: Saving to file failed > '''
Ah. I just tried it out with "xterm -e", and got exactly the same error.
> If I delete the feh part ( so it is only aterm -e ./hold scrot -s -q > 100 ) there is no error message and there is also a image as > "2009-04-05-214611_286x257_scrot.png" > > Though the command > > ``` > scrot -s -q 100 -e 'feh $f' > ''' > > works fine. I am really confused why it is not working with key > combination ( but with toolbar ) and why the error message when > executing with aterm -e !!
I strongly suspect that the shortcut key processor in IceWM launches a shell to process the command; in fact, I can't really imagine what else it could do, given that you can use shell constructs as programs to be launched. So the above is, unfortunately, a preview of what happens "inside" IceWM when you try to run your 'scrot' command. As a test, I just tried it out myself - and got the same result as you (i.e., nothing.)
The simple solution is to do what I've always done with it (which is, I suppose, why I never had a problem with it) - make it a toolbar icon. Just add the following to ~/.icewm/toolbar:
prog 'Snap' 'image_16x16.xpm' scrot -s -q 100 -e 'feh $f'
I have something similar, and it's worked fine ever since I set it up.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Thomas Adam [thomas.adam22 at gmail.com]
2009/4/5 Ben Okopnik <ben@linuxgazette.net>:
> On Sun, Apr 05, 2009 at 10:08:59PM +0530, J. Bakshi wrote: >> >> Thanks for the debugger. It will also help me to debug other command too. >> It has helped me to catch the error. > > Good! I'm glad that got you further along. > >> First of all I created "hold" script as you shown above. Then I >> executed the actual command as >> >> ```` >> joy@debian:~/bin$ aterm -e ~/bin/hold scrot -s -q 100 -e 'feh $f' >> '''' >> >> and bingo !! aterm is in holding stage. It allow me to take the >> sceenshot but after that the error is >> >> ``` >> giblib error: Saving to file failed >> ''' > > Ah. I just tried it out with "xterm -e", and got exactly the same error.
Because most terminal emulators won't do their option-parsing in serial with multiple actions. Hence what you're asking for here is:
xterm -options -e foo && bar
[..snip..]
-- Thomas Adam
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 11:26:27PM +0100, Thomas Adam wrote:
> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>: > > > > Ah. I just tried it out with "xterm -e", and got exactly the same error. > > Because most terminal emulators won't do their option-parsing in > serial with multiple actions. Hence what you're asking for here is: > > `` > xterm -options -e foo && bar > ''
Actually, no: the 'feh $f' is supposed to be an argument to 'scrot' (clearly, '$f' is not a shell variable of any sort.) The problem happens because '-e' screws up even that minor level of indirection (i.e., it strips off the single quotes, and then - oh, brother.) To take it a step back, that's why I wasn't going to tell Joydeep to do
xterm -e 'blah; read' or xterm -e '(blah; read)'
That's the other reason for the 'hold' script vs. the '-hold' option: the script actually allows you a little more flexibility after the '-e' since everything that comes after it is interpeted by the shell - a nice little bonus. The default '-e' processing is abysmally crude, in my opinion.
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Thomas Adam [thomas.adam22 at gmail.com]
2009/4/5 Ben Okopnik <ben@linuxgazette.net>:
> On Sun, Apr 05, 2009 at 11:26:27PM +0100, Thomas Adam wrote: >> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>: >> > >> > Ah. I just tried it out with "xterm -e", and got exactly the same error. >> >> Because most terminal emulators won't do their option-parsing in >> serial with multiple actions. Hence what you're asking for here is: >> >> `` >> xterm -options -e foo && bar >> '' > > Actually, no: the 'feh $f' is supposed to be an argument to 'scrot' > (clearly, '$f' is not a shell variable of any sort.) The problem happens > because '-e' screws up even that minor level of indirection (i.e., it > strips off the single quotes, and then - oh, brother.) To take it a > step back, that's why I wasn't going to tell Joydeep to do
I thihk we're talking about two different things here -- my example was poor, but of course still valid. In your case, as is such an old-age thing to do, spawn the app in an explicit shell (sh -c).
-- Thomas Adam
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 11:57:38PM +0100, Thomas Adam wrote:
> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>: > > On Sun, Apr 05, 2009 at 11:26:27PM +0100, Thomas Adam wrote: > >> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>: > >> > > >> > Ah. I just tried it out with "xterm -e", and got exactly the same error. > >> > >> Because most terminal emulators won't do their option-parsing in > >> serial with multiple actions. Hence what you're asking for here is: > >> > >> `` > >> xterm -options -e foo && bar > >> '' > > > > Actually, no: the 'feh $f' is supposed to be an argument to 'scrot' > > (clearly, '$f' is not a shell variable of any sort.) The problem happens > > because '-e' screws up even that minor level of indirection (i.e., it > > strips off the single quotes, and then - oh, brother.) To take it a > > step back, that's why I wasn't going to tell Joydeep to do > > I thihk we're talking about two different things here -- my example > was poor, but of course still valid. In your case, as is such an > old-age thing to do, spawn the app in an explicit shell (sh -c).
What, like this?
xterm -e sh -c scrot -s -q 100 -e 'feh $f'
Sorry, that still won't work. Although setting up the shortcut key command as "sh -c scrot -s -q 100 -e 'feh $f'" does have some effect: it takes a full-screen screenshot (instead of the nice 'select a shot and display the result' functionality that the above is supposed to provide.)
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Ben Okopnik [ben at linuxgazette.net]
On Sun, Apr 05, 2009 at 07:08:35PM -0400, Benjamin Okopnik wrote:
> On Sun, Apr 05, 2009 at 11:57:38PM +0100, Thomas Adam wrote: > > > > I thihk we're talking about two different things here -- my example > > was poor, but of course still valid. In your case, as is such an > > old-age thing to do, spawn the app in an explicit shell (sh -c). > > What, like this? > > `` > xterm -e sh -c scrot -s -q 100 -e 'feh $f' > '' > > Sorry, that still won't work. Although setting up the shortcut key > command as "sh -c scrot -s -q 100 -e 'feh $f'" does have some effect: > it takes a full-screen screenshot (instead of the nice 'select a shot > and display the result' functionality that the above is supposed to > provide.)
Following up to myself, but:
xterm -e sh -c "/usr/bin/scrot -s -q 100 -e 'feh $f'"
works fine. I figured that some level of fiddling with "sh -c" would produce a result.
Joydeep, you should be able to set up your hot-key combo with this. I'll let you experiment with it, since I'm busy waging a battle (seems like a losing one, unfort) to get WiFi working on my new Acer Aspire netbook. "One time-suck at a time" should be my motto, dammit...
-- * Ben Okopnik * Editor-in-Chief, Linux Gazette * https://LinuxGazette.NET *
Thomas Adam [thomas.adam22 at gmail.com]
2009/4/6 Ben Okopnik <ben@linuxgazette.net>:
> On Sun, Apr 05, 2009 at 11:57:38PM +0100, Thomas Adam wrote: >> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>: >> > On Sun, Apr 05, 2009 at 11:26:27PM +0100, Thomas Adam wrote: >> >> 2009/4/5 Ben Okopnik <ben@linuxgazette.net>: >> >> > >> >> > Ah. I just tried it out with "xterm -e", and got exactly the same error. >> >> >> >> Because most terminal emulators won't do their option-parsing in >> >> serial with multiple actions. Hence what you're asking for here is: >> >> >> >> `` >> >> xterm -options -e foo && bar >> >> '' >> > >> > Actually, no: the 'feh $f' is supposed to be an argument to 'scrot' >> > (clearly, '$f' is not a shell variable of any sort.) The problem happens >> > because '-e' screws up even that minor level of indirection (i.e., it >> > strips off the single quotes, and then - oh, brother.) To take it a >> > step back, that's why I wasn't going to tell Joydeep to do >> >> I thihk we're talking about two different things here -- my example >> was poor, but of course still valid. In your case, as is such an >> old-age thing to do, spawn the app in an explicit shell (sh -c). > > What, like this? > > `` > xterm -e sh -c scrot -s -q 100 -e 'feh $f' > '' > > Sorry, that still won't work. Although setting up the shortcut key > command as "sh -c scrot -s -q 100 -e 'feh $f'" does have some effect: > it takes a full-screen screenshot (instead of the nice 'select a shot > and display the result' functionality that the above is supposed to > provide.)
No, look at the quoting :
xterm -e sh -c "/usr/bin/scrot -q 100 -s -e 'feh $f'"
Or some variation thereof should sort you out.
-- Thomas Adam
J. Bakshi [j.bakshi at unlimitedmail.org]
> > On Sun, Apr 05, 2009 at 07:08:35PM -0400, Benjamin Okopnik wrote: > > On Sun, Apr 05, 2009 at 11:57:38PM +0100, Thomas Adam wrote: > > > > > > I thihk we're talking about two different things here -- my > > > example was poor, but of course still valid. In your case, as is > > > such an old-age thing to do, spawn the app in an explicit shell > > > (sh -c). > > > > What, like this? > > > > `` > > xterm -e sh -c scrot -s -q 100 -e 'feh $f' > > '' > > > > Sorry, that still won't work. Although setting up the shortcut key > > command as "sh -c scrot -s -q 100 -e 'feh $f'" does have some > > effect: it takes a full-screen screenshot (instead of the nice > > 'select a shot and display the result' functionality that the above > > is supposed to provide.) > > Following up to myself, but: > > `` > xterm -e sh -c "/usr/bin/scrot -s -q 100 -e 'feh $f'" > '' > > works fine. I figured that some level of fiddling with "sh -c" would > produce a result. > > Joydeep, you should be able to set up your hot-key combo with this. > I'll let you experiment with it, since I'm busy waging a battle > (seems like a losing one, unfort) to get WiFi working on my new Acer > Aspire netbook. "One time-suck at a time" should be my motto, > dammit... > >Hello Ben and Thomas,
I really enjoyed the discussion. I have come to know many other things from this discussion.
aterm -e sh -c "/usr/bin/scrot -s -q 100 -e 'feh $f'"
works for me too
Though it only takes the full screen shot with out preview in feh and even with key combination it open the terminal. I hope little more digging with sh can do the trick. I'll experiment with it.
thanks a lot