× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Ouch! But thanks, Scott. (This will teach me for dabbling in Unix
stuff.)
I'll work through your suggestions and try to understand a little more
before trying this again.
Cheers,
Lorne.

"Scott Klement" <midrange-l@xxxxxxxxxxxxxxxx> wrote in message
news:<mailman.4264.1261171846.31599.midrange-l@xxxxxxxxxxxx>...
Hi Lorne,

Change your script to look like this:

find "${1}" -mtime +${2} -exec rm -d "{}" \;

Change your CL to look like this:

chgVar &cmd +
('/home/myDir/myScript.qsh "' || &path || '"' |> &days)

Or better yet, change your CL to avoid the ugly concatenation and do
this instead:

addenvvar envvar(MYPATH) value(&PATH)
addenvvar envvar(MYDAYS) value(&DAYS)
strqsh cmd('/home/myDir/myScript.qsh "$MYPATH" $MYDAYS')

Be aware that envvar's are case sensitive... I used all caps above,
and
you don't have to do that, but make sure your variables have the same
case in both the addenvvar and the strqsh statements

Also the envvar named PATH has a special meaning in QSH, so don't use
the name PATH... though MYPATH works fine.

Finally, eliminate the awful '*.*' from your command. This isn't
MS-DOS. *.* means "anything with a . in it" just as *x* means
"anything
with an x in it"

But it makes no sense whatsoever to use a wildcard here. the 'find'
command already looks in all files and subdirectories of a given
directory. Using a wildcard means that 'find' could potentially choke

on the max number of parameters allowed -- and there's no reason to do
that!

Your final command call should end up looking like this:

/home/myDir/myScript.qsh "/Client files/Input/Black_H/Archive" 30

Actually... in my opinion, it's also a bad idea to hard code the
directory name of your script. How can you have development, QA, and
production versions of your script if you hard-code the directory?

Even if you do decide to hard-code it, why would it be in /home? That

makes no sense either. That would be like installing Windows
software
into the "My Documents" directory. It doesn't belong there. It
belongs in "Program Files". Or in the IFS, that would be
/usr/local/bin
... Though I could see using /home/lorne (or whatever) while in
development... which goes back to my point about not hard-coding the
directory :)


Sturgeoff, Lorne wrote:
Adding the double quotes is my problem. I've tried every way I can
think
of including adding the double quotes in the database data. No
matter
what I try QSHELL is parsing the path at the first blank character
regardless of the fact that the path contains double quotes. I must
be
missing something obvious.

When I run this in debug and look at the &CMD string, I see the
following:
'/home/AICOPR/IFSPurge.qsh "/Client files/Input/Black_H/Archive/*.*
"
30'

Qshell is looking for directory, 'Client. Then,
files/Input/Black_H/Archive/*.*.

Lorne.

"Scott Klement" <midrange-l@xxxxxxxxxxxxxxxx> wrote in message
news:<mailman.4254.1261169933.31599.midrange-l@xxxxxxxxxxxx>...
Oksy... then you clearly aren't including double-quotes. Add them.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.