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

--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf <noise@audiomisc.co.uk> wrote:
> #! /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.

Sigh, shell and whitespace is always a mess. However:
https://yakking.branchable.com/posts/whitespace-safety/

$ cat printargs.c
#include <stdio.h>
int main(int argc, char *argv[])
{ int i=0;
while (argc) {
printf("%s\n", argv[i]);
i++;
argc--;
}
}

$ gcc -o printargs printargs.c

$ ./printargs "hello world" something else
../printargs
hello world
something
else
$ bash
$ set -- "hello world" something else
$ ./printargs "$@"
../printargs
hello world
something
else
$ exec ./printargs "$@"
../printargs
hello world
something
else

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

In article <T-B*rkdPy@news.chiark.greenend.org.uk>, 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!

If curious, there are examples of what I've already written here
http://www.audiomisc.co.uk/software/index.html
including the sources.

The only dodge I've thought of thus far is to put 'spaced-out' files into a
specific input directory. Then a click on the ROX app icon can make it cat
the directory content list of file names into a text file to get the
name(s) with spaces - and then use that list to change the names. (i.e.
force the C to read each line until it hits an EOF or return.That should
sidestep the problem. But it shouldn't really be happening at all. I've
assumed this is for the usual reason - I'm a crap programmer. But maybe
it's something else this time.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf <noise@audiomisc.co.uk> wrote:
> 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!

I think you might have to do some digging. My 'printargs' example does the
right thing, so maybe you could try running that under ROX (piping stdout to
a file if needs be to capture the output) and see if it works. And then try
running your app with "$@" after doing a 'set --' to force the args. Also
try running printargs in xterm. Could be xterm, could be ROX, could be
something else - more needed investigation to get to the bottom of it.

Note that argc includes the program name, so running the binary with no args
would give argc=1.

Theo

Jim Lesurf <noise@audiomisc.co.uk> writes:
> 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.

My first step would be to use strace to find out where things go
wrong. Specifically find the PID of rox-filer, then run:

strace -o trace -e trace=execve -p PID

The ‘trace’ file should end up with the commands actually executed and
their arguments. It should be enough to figure out which component has
gone wrong.

Your script looked OK and the _current_ rox-filer source looks OK, but I
don’t know what version you’re running.

> 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!

If, hypothetically, it just concatenated the AppRun path and the
filename and passed the result to the shell then you’d get the behavior
you see, since the shell would see each part of the filename as a
separate argument.

--
https://www.greenend.org.uk/rjk/

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

--
Basic

On 23.07.2022 at 14:49, Folderol scribbled:

> 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

That would only work if there is exactly one space in the filename.

I have added two functions to my .bashrc for quickly processing all
files in a directory in both directions. One replaces the spaces with
underscores and the other one does the opposite.

= 8< ==================================================================

spaces2underscores ()
{ targetdir="$*"
if [ ! -z "$1" ]
then
if [ -d "${targetdir}" ]
then
oldpwd=$(pwd)
else
echo "Not a valid directory."
return 2
fi
fi
read -n1 -p "Rename all files in ${targetdir}? [y/N] "
case ${REPLY} in
"Y" | "y" )
if [ -w "${targetdir}" ]
then
cd "${targetdir}"
else
echo
echo "Permission denied."
return 77
fi
fncounter=0
for fn in *
do
newfn=$(printf "${fn}" | tr ' ' '_')
if [ "${newfn}" != "${fn}" ]
then
mv "${fn}" "${newfn}"
fncounter=$((${fncounter}+1))
fi
done
cd "${oldpwd}"
echo
echo "Successfully replaced spaces by underscores in\
${fncounter} filename(s)." echo
;;
* )
echo
echo "Operation aborted."
echo
return 0
;;
esac
unset targetdir oldpwd REPLY fncounter fn newfn
}

underscores2spaces ()
{ targetdir="$*"
if [ ! -z "$1" ]
then
if [ -d "${targetdir}" ]
then
oldpwd=$(pwd)
else
echo "Not a valid directory."
return 2
fi
fi
read -n1 -p "Rename all files in ${targetdir}? [y/N] "
case ${REPLY} in
"Y" | "y" )
if [ -w "${targetdir}" ]
then
cd "${targetdir}"
else
echo
echo "Permission denied."
return 77
fi
fncounter=0
for fn in *
do
newfn=$(printf "${fn}" | tr '_' ' ')
if [ "${newfn}" != "${fn}" ]
then
mv "${fn}" "${newfn}"
fncounter=$((${fncounter}+1))
fi
done
cd "${oldpwd}"
echo
echo "Successfully replaced underscores by spaces in\
${fncounter} filename(s)." echo
;;
* )
echo
echo "Operation aborted."
echo
return 0
;;
esac
unset targetdir oldpwd REPLY fncounter fn newfn
}

export speces2underscores underscores2spaces

--
With respect,
= Aragorn =

On Sat, 23 Jul 2022 14:49:02 +0100
Folderol <general@musically.me.uk> wrote:

>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
>
>

Scratch that!

What is happening is that it is being split up into separate arguments.
You need a loop to scan them all, pick up the text and join them together
with underscores.

Not sure where you go from here. Whatever is actually processing the file needs
to find out the real name.

--
Basic

On 23.07.2022 at 16:07, Aragorn scribbled:

> echo "Successfully replaced spaces by underscores in\
> ${fncounter} filename(s)." echo
> ;;

My apologies for the way my newsreader garbled that. That last "echo"
command should of course go on a new line.

--
With respect,
= Aragorn =