removing period from file names

[Brian K. White]

There is nothing wrong with multiple "." in a filename. It's not silly 
at all.
What makes you think that is the cause of any problem?
I don't mean "because it's not working", I mean, what error message did 
you read that suggested the problem had to do with the dots?

Maybe script.sh has a problem with them, but that would just mean 
script.sh is silly and needs to be fixed.
Are you maybe trying to strip off or detect the extension in the script?
I have no idea what you're trying to do in the script, so, blindly, here 
are are a few shell brace-expansions that are handy for commonly needed 
file/path name operations.
Get the leading path, strip the leading path, get the extension, strip 
the extension.
These work in at least bash and ksh93, probably also zsh and dash. 
Maybe/maybe-not simpler bourne shells like ash, busybox, ksh88, 
sco/solaris sh, etc
(basically, any normal linux since decades ago, but maybe not in say, an 
android phone or an emergency boot shell.)

X0_ORIG_FULL=/path/to/foo/T01245.John.Smith_Statement.Oct2019.pdf
X1_ORIG_DIRNAME="${X0_ORIG_FULL%/*}"
X2_ORIG_BASENAME="${X0_ORIG_FULL##*/}"
X3_ORIG_EXT="${X0_ORIG_FULL##*.}"
X4_ORIG_BASENAME_NO_EXT="${X2_ORIG_BASENAME%.*}"

set |grep "^X[0-9]_"
X0_ORIG_FULL=/path/to/foo/T01245.John.Smith_Statement.Oct2019.pdf
X1_ORIG_DIRNAME=/path/to/foo
X2_ORIG_BASENAME=T01245.John.Smith_Statement.Oct2019.pdf
X3_ORIG_EXT=pdf
X4_ORIG_BASENAME_NO_EXT=T01245.John.Smith_Statement.Oct2019


Separately, this is not the source of your problem in this case, but 
still, for that fp system command I would not as a general rule embed 
the quotes within the variable. Not because it shouldn't work, it's just 
not good practice to my mind. The quotes are not in fact part of the 
filename. So, say you want to do anything else with that info, like save 
it in a field, you would have to strip them back out, or keep two 
variables, one original and one with the quotes, etc. Keep the var 
containing only the actual data, and apply containers  and delimiters 
like quotes from outside.

system "mv \"" { orig { "\" \"" { new { ""

or if you don't like trying to read backslashes...

q = chr(34")
system "mv" < q{orig{q < q{new{q

You can also disable many of the problem characters by setting bash 
behavior options at the beginning of the command:
system "set -f +H +B ;mv" < q{orig{q < q{new{q

To diagnose your problem instead of guessing that something "seems like" 
something,
use "set -x" and capture stdout and sdterr to temp files. You can do 
that inside your script, and in the system command.

This uses another handy expansion, to take $0, which would be 
"/path/to/myscript.sh", and get ".path.to.myscript.sh"
to make temp file names like "/tmp/.path.to.myscript.sh.32767.out"
Which gets you several things at once:
the filenames are reasonably unique and automatically reasonably safe 
from collision with other instances of itself and other processes if you 
use the exact same code in multiple places,
the filenames sort to the top of most file listing utils because of the 
leading "." which came from the leading "/"
all the information of the full path is converted to a plain filename, 
so you know what actually generated the temp file, even if you had 
multiple copies of myscript.sh in different dirs.

myscript.sh:
-------------------
#!/bin/bash
set -x
t=/tmp/${0//\//.}.${$}
exec 1>${t}.out 2>${t}.err
set
# stuff here ...
----- end --------

That will capture stdout to *.out and stderr to *.err
the 2nd 'set' command (without args) will dump the environment variables 
into *.out at the beginning of the script, which may provide 
explainations for whatever error messages you get from the commands that 
come later. Like if you get a "command not found" error later, maybe the 
PATH in the env dump at the top will explain that. etc. This is a 
general example. Your problem isn't likely PATH related but more likely 
something to do with quoting a string or splitting a string at the first 
dot instead of the last dot etc.

To do something similar in processing around some existing command:
say you had:
system "foo args..."

change that to
system "foo args... >/tmp/.prc.foo.${$}.out 2>/tmp/.prc.foo.${$}.err"

And just go look what the temp files contain. What comes next depends of 
what clues turn up in them.

-- 
bkw

On 10/2/19 9:16 PM, scooter6--- via Filepro-list wrote:
> I have a bunch of XML data I import to a filePro database (5.6.10R4) on
> CentOS 7
>
> Several of the fields are names of files that have been uploaded to the
> same server
>
> We get silly client that like to name their files something like:
> T01245.John.Smith_Statement.Oct2019.pdf
>
> Through my code I come up with my own naming convention and I do a system
> call to a script that renames the file - but it doesn't seem to work on
> file names that have several '.' in them
>
> I pass dd=chr("34"){name of the existing file name{chr("34") but that
> doesn't seem to work
> dc=chr("34"){name I am changing file to{chr("34")
>
> system "/path/to/my/script.sh"<dc<dd  (which is a script that simply does a
> mv in the directory the files are located)
>
> Wouldn't filepro be passing quotes "  in this instance so Linux wouldn't
> then care if the name of the file had multiple '.' in it?   It works as
> designed for any file names that don't have multiple '.' in them...
>
> thanks
>
> Scott
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20191002/783a4f32/attachment.html>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list