Re: Recursive touching... Whoo hoo!

[Scott Klement <klemscot@xxxxxxxxxxxx>]

hi Joe,

> What's the easiest programmatic way to touch a file in the IFS?  I
> wanted to do "touch *.jsp" in a folder, and I get the dreaded "too many
> arguments" error, because there are too many files in the folder (don't
> get me started on how stupid this is).

Yep...  The whole "too many arguments" thing is one of the more
frustrating thing about Unix shells.

One simple (though, not especially efficient) workaround would be to use
the QShell find command.  For example:

   find /path/to -name '*.jsp' -exec touch {} \;

What that will do is invoke a separate process that runs the "touch"
command for every file named *.jsp in the /path/to directory.  Since it
only passes one filename for each invocation of "touch", there's no
problems with the argument list being too long.

But, if you have 400 files, it'll start up 400 jobs, one by one, to run
touch in.  Not very efficient!!  For a small number of files, or a
one-time-only situation, this is a reasonable solution because it's
simple.

> So, now I'd like some suggestions on the simplest way to:
>
> 1. Touch a single file
> 2. Specify a folder and touch every JSP in that folder and all its
> subfolders.

That's what that command above does...


> A straightforward multi-step process using temporary files and standard
> shell commands is an acceptable possibility.  Simple code for doing it
> from RPG is also fine.

There are many other ways to do it.   One relatively easy way is to use
Qshell's find command to dump a list of things to a file, and have a
program (RPG, C, Java, whatever you like) read that file and use the IFS
APIs (or Java classes) to "touch" them.  (for example with the open() API
in C or RPG)

I wouldn't have a shell script touch each file individually, because that
won't be any more efficient than using "find".

>
> Last place option is a Java program.
>

Of course, you could do the whole thing purely with the IFS APIs or
Java classes and eliminate QShell altogether.  That'll be even more
efficient, but adds more complexity.

As always, you have to decide for yourself what the balance between
efficiency and complexity should be.