Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Reading the backlash character from a text file..

Status
Not open for further replies.

mucklow

Programmer
May 22, 2001
40
US
Hi all,
I'm having a problem with the gets command. I'm generating a dos directory listing from a text file that is generated by my program on the fly. My problem is when I say [gets $dos_text_file] when it reads a line such as c:\temp\test it automatically treats the \ as an escape character, so what the program sees is "c: emp est". What is the trick with gets to disable command processing? I tried variations like {[gets $dos_text_file]}, "[gets $dos_text_file]", ([gets $dos_text_file])... etc but none of them worked. Has anyone experienced this problem? I would think its common, and I'm sure its a simple solution I overlooked somewhere. Please advise.
 
Update: after further testing, I found that I had the right idea with using the quotes:
set info "[gets $file]"
$info is now set to "Directory of C:\TEMP" for example.
My problem was a few lines below that when I tried to grab the last word of the string using:
set info2 [lindex $info end]
$info2 was now set to "C: EMP"
I figured that lindex was my problem and not gets, but it seems the lindex command won't cooperate like the gets command did. I tried using
set info2 "[lindex $info end]"
but the result was
$info2 was now set to "C: EMP".
Very odd, but at least I narrowed it down and will use the old fashioned method to grab the last word of the string. If anyone has any input on this please share it. Thanks, Travis
 
Yes, it's your lindex command that's causing the problem in this case. gets doesn't handle escape or quoting characters special in any way; they're just part of the string value returned. However, the Tcl quoting characters ("{}\) are used to build well-formed lists.

For those who haven't used lists much, let me make a digression. A Tcl list is a whitespace-separated sequence of elements, and an element can be any string value. But what if you want to store a string like "New York" as one of the list elements? Without special treatment, the space between "New" and "York" looks like any other whitespace characters separating elements, and so "New York" would get split into two separate elements.

In cases like this, you use the standard Tcl quoting mechanisms to delimit your elements, in exactly the same way that you'd quote arguments in a Tcl command. So, we could build up a list of states like this:

[tt]set states "California {New York} Oregon"[/tt]

The backslash character is a "live" quoting character within lists so that we can have "{" as a literal list element. For example:

[tt]set weird "first second \{ fourth"[/tt]

Tcl list-building commands, like list, lappend, lreplace, and split handle this quoting for you automatically. It's only in cases like those above where you're manually building a list where you need to worry about proper element quoting.

Anyway, in your case, lindex interprets the "\" characters in your string as an escape character, just as you found out.

In situations like this, you really do want to use Tcl string commands to parse your string. A simple case where your parsing could fail: What if one or more of the directories contained a space (like "C:\Program Files")?

In general, you should never use a list command to parse a string unless you can ensure that the string is also a well-formed list. Otherwise, the list commands could either garble the result (like in this case) or raise and error condition (more frequently) if they encounter elements that aren't well-formed. - Ken Jones, President
Avia Training and Consulting
866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax
 
Thanks for your advice. However, I have run into just that problem you mentioned. The program I'm creating takes a set of characters and replacement characters defined by the user. It then searches a directory also input by the user for all filenames and sub-directories containing the specified characters and replaces them. For example filenames and directories with spaces in the name can be filtered out to replace the space with "_" or just removed from the name. Mainly this is for moving data from NT to UNIX but has other uses. My problem is now trying to rename a file inside a directory that has a space in the name. The list of files/directories is generated thru a dos batch file (dir /s $input_directory). If I try to rename "c:\temp\test folder\test 123.txt" to "c:\temp\test folder\test_123.txt" for example it cannot find the file. I tried editing the string like "{c:\temp\test folder\test 123.txt}" or "c:\temp\{test folder}\test 123.txt" but with no luck. By the way I worked around the backlash character problem within the filename so the syntax above isn't exactly how its in the program. I have it set up to rename all the directories at the end of the program instead of in the middle along with the files, I may have to switch that around but that created a different problem itself (it couldnt find the file as listed by the dos dir because the directory had already been renamed). Sometimes programming is tricky! Any tips would be greatly appreciated.
Travis Mucklow
Northrop Grumman
 
update (again):
I've worked around my problem. By renaming all directories in the first phase of the program, then re-running the batch file and creating a new file list with the new directory names, the program worked. Its a useful tool, if anyone is interested feel free to email me. It takes a root directory (C:\Program files, for example) and recursively searchs all filenames/sub-directories for characters you specify, such as a space " " or others (%,#,*... etc) and can either remove them or replace them with a different character. It was a vital tool for our data migration from NT to UNIX.
Travis Mucklow
Northrop Grumman
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top