#! /bin/sh
exec xterm -fn 10x20 -sb -rightbar -sl 200 -hold -e `dirname $0`/RunImage "$@"
(exec command all on one line)
This then calls the main code in the file 'RunImage' in the app and runs it in a terminal. The main code I generate from a 'C' program as most of my programming is in 'C'.
As you'd expect it executes the RunImage and sends it the context info via the "$@" for the program to get via its 'environment' 'arguments' input. In particular, if I drag-and-drop a file icon onto the app's directory icon
ROX runs the app and gives it the full pathname of the file via the above.
So the program can find it as an input argument. Thus knows what file I
want it to deal with.
So "$@" should do the right thing, and I'm puzzled why it doesn't.
Perhaps xterm or your RunImage isn't handling args in the right way?
Theo> <theom+news@chiark.greenend.org.uk> wrote:
So "$@" should do the right thing, and I'm puzzled why it doesn't.
<AOL> Me too! :-//
Perhaps xterm or your RunImage isn't handling args in the right way?
Quite possibly. I'm a lousy programmer. However when I tried and got my current program to print out the arg count 'seen' by the executable 'RunImage' I'd generated from 'C' using gcc it always gives the arguments count as '2'. Which I assume implies that the launching code ending with
"$@" is only sending until the first space in the filename it got.
Maybe this is a bug (aka 'feature') in ROX-Filer? And when *it* sends the file name to AppRun (the code that starts the xterm, etc) *it* fails to
read everything after the first space in the name of the file dropped on
the ROX-app icon. :-/ If so, real PITA!
Quite possibly. I'm a lousy programmer. However when I tried and got my current program to print out the arg count 'seen' by the executable 'RunImage' I'd generated from 'C' using gcc it always gives the arguments count as '2'. Which I assume implies that the launching code ending with
"$@" is only sending until the first space in the filename it got.
Maybe this is a bug (aka 'feature') in ROX-Filer? And when *it* sends the file name to AppRun (the code that starts the xterm, etc) *it* fails to
read everything after the first space in the name of the file dropped on
the ROX-app icon. :-/ If so, real PITA!
On Thu, 26 May 2022 15:23:44 +0100
Jim Lesurf <noise@audiomisc.co.uk> wrote:
I tend to run ROX-Filer on my Linux machines and then write simple ROX >>'apps' as a way to carry out various simple routine file-processing tasks. >>Overall this works fine for me, but in some cases I hit a snag that I don't >>know how to deal with. The cause is common, so maybe someone here can
point out how I can deal with it...
For those who don't use it: A Rox 'app' essentially is a directory that >>contains some specific items the filer uses to tell it is an app, not a >>plain directory. The entry point is an executable file with the name >>"AppRun". The contents are read and executed. Typically I use this to >>contain something like
#! /bin/sh
exec xterm -fn 10x20 -sb -rightbar -sl 200 -hold -e `dirname $0`/RunImage >>"$@"
(exec command all on one line)
This then calls the main code in the file 'RunImage' in the app and runs it >>in a terminal. The main code I generate from a 'C' program as most of my >>programming is in 'C'.
As you'd expect it executes the RunImage and sends it the context info via >>the "$@" for the program to get via its 'environment' 'arguments' input. In >>particular, if I drag-and-drop a file icon onto the app's directory icon >>ROX runs the app and gives it the full pathname of the file via the above. >>So the program can find it as an input argument. Thus knows what file I >>want it to deal with.
The snag is when I want to process a file provided by someone else *which >>contains space characters (or some other 'control' characters)*.
e.g. the input file may have a leafname "fred the frog.mkv" rather than >>"fred_the_frog.mkv".
The spaces cause only the initial "fred" to be sent as the input file name. >>So the RunImage doesn't get the full *actual* name. (the args count remains >>'2'.)
This is presumably because I shouldn't be using "$@" but some other spec >>that gets the file name sent as a one complete string including the spaces. >>But my noddy knowledge of bash, etc, means I dunno how to fix this. So can >>someone explain, please how to get such names sent as a fill file name >>series of characters. Not split up and lost.
Personally I regard spaces in file names as a PITA, so never use them >>myself. But others do and I then have to 'edit' the names at present to >>avoid the above problem.
BTW if you want to see examples of the ROX apps you can find some here >>http://www.audiomisc.co.uk/software/index.html
mixed in with RISC OS equivalents. Apologies as the programs aren't pretty, >>I'm not a real programmer, but they get the job done in general.
Ta,
Jim
Bit late, but is this what you are looking for?
for f in *\ *; do mv "$f" "${f// /_}"; done
I tend to run ROX-Filer on my Linux machines and then write simple ROX
'apps' as a way to carry out various simple routine file-processing tasks. >Overall this works fine for me, but in some cases I hit a snag that I don't >know how to deal with. The cause is common, so maybe someone here can
point out how I can deal with it...
For those who don't use it: A Rox 'app' essentially is a directory that >contains some specific items the filer uses to tell it is an app, not a
plain directory. The entry point is an executable file with the name >"AppRun". The contents are read and executed. Typically I use this to
contain something like
#! /bin/sh
exec xterm -fn 10x20 -sb -rightbar -sl 200 -hold -e `dirname $0`/RunImage >"$@"
(exec command all on one line)
This then calls the main code in the file 'RunImage' in the app and runs it >in a terminal. The main code I generate from a 'C' program as most of my >programming is in 'C'.
As you'd expect it executes the RunImage and sends it the context info via >the "$@" for the program to get via its 'environment' 'arguments' input. In >particular, if I drag-and-drop a file icon onto the app's directory icon
ROX runs the app and gives it the full pathname of the file via the above.
So the program can find it as an input argument. Thus knows what file I
want it to deal with.
The snag is when I want to process a file provided by someone else *which >contains space characters (or some other 'control' characters)*.
e.g. the input file may have a leafname "fred the frog.mkv" rather than >"fred_the_frog.mkv".
The spaces cause only the initial "fred" to be sent as the input file name. >So the RunImage doesn't get the full *actual* name. (the args count remains >'2'.)
This is presumably because I shouldn't be using "$@" but some other spec
that gets the file name sent as a one complete string including the spaces. >But my noddy knowledge of bash, etc, means I dunno how to fix this. So can >someone explain, please how to get such names sent as a fill file name
series of characters. Not split up and lost.
Personally I regard spaces in file names as a PITA, so never use them
myself. But others do and I then have to 'edit' the names at present to
avoid the above problem.
BTW if you want to see examples of the ROX apps you can find some here >http://www.audiomisc.co.uk/software/index.html
mixed in with RISC OS equivalents. Apologies as the programs aren't pretty, >I'm not a real programmer, but they get the job done in general.
Ta,
Jim
On Thu, 26 May 2022 15:23:44 +0100
Jim Lesurf <noise@audiomisc.co.uk> wrote:
Personally I regard spaces in file names as a PITA, so never use them >myself. But others do and I then have to 'edit' the names at present
to avoid the above problem.
Bit late, but is this what you are looking for?
for f in *\ *; do mv "$f" "${f// /_}"; done
echo "Successfully replaced spaces by underscores in\
${fncounter} filename(s)." echo
;;
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:34:40 |
| Calls: | 6,648 |
| Files: | 12,197 |
| Messages: | 5,329,704 |