We received as input in our application (running on Windows) a list of files. These files were automatically extracted from a database with a script.
Apparently some of the names are containing special characters (like accents) and these characters are rendered as '©' on our side.
How can rename programmatically these text files (around 900'000) to get rid of this character?
We cannot change the source neither re-extract the files.
The problem is that because of this character another program involved with our system does not accept the files.
Have a look at the unix command rename. It allows you to apply a perl regex to the names of a bunch of files. In this case you might want something like:
$ rename 's/[^a-zA-Z0-9]//' *
In debian the rename command is part of the perl package. It should also be available on CPAN.
I ended up creating a new script that reads the input files and search for special characters in their title.
It was quite easy indeed:
string filename = filename.Replace("©", "e");
Since the '©' is in the filename, the script (in C#) is able to recognize it and replace the match accordingly. In this way I can loop through all the folders and subfolders simply reading the filename and change specials characters.
Thank you all for the contributions!
Related
I'm trying to use diff3 in this way
diff3 options... mine older yours
My problem is that I probably can't use it, since all my 3 files contain a "dash" within.
The manual mentions:
At most one of these three file names may be `-', which tells diff3 to read the standard input for that file.
so I probably have to rename filenames before running diff3.
If you know for a better solution or a workaround, please let me know about. Thank you!
At most one of these three file names may be `-', which tells diff3 to read the standard input for that file.
It does not state, that your filenames should not contain dash symbols. It simply says, that if you want to, you can put - instead of one of the names, in which case the standard input will be read instead of reading one of the files.
So, you can have as many dashes in your filenames as you like and diff3 should work just fine.
However, on Windows putting filenames in "" for escaping space characters does not work, and I failed to find a suitable workaround. However, you can automatize the process of renaming files (if the files are relatively small, this would not even be too inefficient):
#echo off
copy %1 tempfile_1.txt
copy %2 tempfile_2.txt
copy %3 tempfile_3.txt
"C:\Program Files (x86)\KDiff3\bin\diff3.exe" -E tempfile_1.txt tempfile_2.txt tempfile_3.txt
del tempfile_1.txt tempfile_2.txt tempfile_3.txt
Put this in a file like diff3.cmd, then run diff3.cmd "first file.txt" "second file.txt" "third file.txt".
P.S. Moving files would be more efficient (if they are on the same disk volume as the script, which they are not in your case), you could even move them back to where they were initially, but for some time they would not be present at their original folder.
I don't understand the behaviour of the COPY command when using a wildcard.
I have a single text file in C:\Source called mpt*.asm and I want to copy it to C:\Dest. This is needed from a batch script, and I can't be sure of the exact name of mpt*.asm (it may be mpt001.asm for example). The destination name should be exactly mpt.asm.
If I use:
COPY C:\Source\mpt*.asm C:\Dest\mpt.asm
The file file is copied, but has a extra (0x1A) character appended to the end of the file.
If I use:
COPY C:\Source\mpt*.asm C:\Dest\mpt.asm /B
I don't get this spurious character.
If I don't use a wildcard, I don't get the spurious character either. It seems unlikely there is a bug in COPY, but this behavior seems unexpected.
Is there a way of doing this copy without resorting to using /B?
I have never seen that before, but it does append an extra arrow character for me too.
You can work around the issue using xcopy instead.
echo f| xcopy C:\Source\mpt*.asm C:\Dest\mpt.asm
If you read copy /? it says
To append files, specify a single file for destination, but multiple files
for source (using wildcards or file1+file2+file3 format).
So by using a single filename as the the dest, and using a wildcard in the source, it may interpret that as appending, which may be what the extra character is for, but as you aren't appending anything you can see it.
I'm only guessing but that may explain it.
I am quite stuck; I need to compress the content of a folder, where I have multiple files (extension .dat). I went for shell scripting.
So far I told myself that is not that hard: I just need to recursively read the content of the dir, get the name of the file and zip it, using the name of the file itself.
This is what I wrote:
for i in *.dat; do zip $i".zip" $i; done
Now when I try it I get a weird behavior: each file is called like "12/23/2012 data102 test1.dat"; and when I run this sequence of commands; I see that zip instead of recognizing the whole file name, see each part of the string as single entity, causing the whole operation to fail.
I told myself that I was doing something wrong, and that the i variable was wrong; so I have replaced echo, instead than the zip command (to see which one was the output of the i variable); and the $i output is the full name of the file, not part of it.
I am totally clueless at this point about what is going on...if the variable i is read by zip it reads each single piece of the string, instead of the whole thing, while if I use echo to see the content of that variable it gets the correct output.
Do I have to pass the value of the filename to zip in a different way? Since it is the content of a variable passed as parameter I was assuming that it won't matter if the string is one or has spaces in it, and I can't find in the man page the answer (if there is any in there).
Anyone knows why do I get this behavior and how to fix it? Thanks!
You need to quote anything with spaces in it.
zip "$i.zip" "$i"
Generally speaking, any variable interpolation should have double quotes unless you specifically require the shell to split it into multiple tokens. The internal field separator $IFS defaults to space and tab, but you can change it to make the shell do word splitting on arbitrary separators. See any decent beginners' shell tutorial for a detailed account of the shell's quoting mechanisms.
I have a number of files in a folder, by mistaken in some of files I enter the wrong name
for example :
filename like : abcefxyz.txt while I suppose to enter abcdevwxyz.txt
that is I simply want to replace ef string in filename with devw
how can I do this using command prompt?
please help...
EDITED
I have a thousands of files whose name like : SomethingLongString_OutdoorGames_DateTime.txt
(which I suppose to enter) but
Accidently in some of files, may be hundreds or thousands in number, I have enter SomethingLongString_IndoorGame_DateTime.txt
I simply want to replace IndoorGame string in filename with OutdoorGamestring (precisely saying).
Here SomethingLongString and DateTime strings in filename is different for different file.
I think this example is more helpful to understand my problem...
on windows use
I dont know how to replace some chars with others,but u can rename this way
dirpath> ren abcefxyz.txt abcdevwxyz.txt
DUNNO.. if they are all TXT files then isolate them in a folder.
From there use Advanced Renamer to a file with NO extension
this way you can use 26 letters to rename the bunch.
CMD use would be Ren A* A (1,2,3,4 etc)
or XCOPY a* A using an older computer..
in a batch you could use for # (filename) do (ren) statements
Would this help?
I am using a perl script to read in a file, but I'm not sure what encoding the file is in. Basically, my file is a list of book titles, but each book has other info associated with it (author, publication date, etc). So each book title is within a discrete chunk of data for the book. So I iterate through the file line by line until I find the regular expression '/Book Title: (.*)/' and take what's in the paren. Then, I create a separate .txt file with the name of the text file being my book. However, in my unix server, when I look at the name of the file, it's actually not, for example, 'LordOfTheFlies.txt' but rather 'LordOfTheFlies^M.txt'
What is this '^M'? Is that a weird end of line encoding I'm not taking into account? I tried chomp but it doesn't seem to be working. What is the best file encoding for working with perl?
It's the additional carriage return character that Windows systems insert before line feed characters (M == 13th letter, hence ASCII 13 is visualised as ^M).
It has nothing to do with file encoding, it's just the line ending policy biting you. Perl is usually good at handling line ending characters correctly, but if they occur somewhere else than the end of a line you have to do it yourself. You can use s/\r// instead of chomp() to get them out.
Before processing the file, you need to know the encoding of the file, which is determined by the producer of the file.
That "^M" is control-M, which is a carriage return, and is not needed in Unix file systems.Looks like the file is created in Unix and transferred to Windows. It can also be added with ftp when text file are transfered as binaries.
Try chop, instead of 'chomp'. Chomp removes the 'new line character'. s/\r// is also good.
For your general question, you might want to use appropriate module for the file type you have to make your life easier and better with Perl.