Help Starting excel from tcl, with spaces in directory path

[Zoner]

I am trying to start excel from within tcl, but run into a problem when
the path has spaces in it.
I am running windows xp...

1: exec cmd.exe /k start $excelFileName &
- This command works great if there are no spaces in the file name...
- Example, c:/documents and settings/dirname/file.csv will fail...
- If the path does have spaces, I will see a command window pop up with
the
filename as the title.

2: exec cmd.exe /k start "Title" $::smp::custom(file) &
- Tried to add the Title argument to the command
- Still fails...

3. exec cmd.exe /k start "Title" D:/Documents and
Settings/sheltonm/Desktop/test.csv &
- Tried sending it without the variable, still fails.

4. exec cmd.exe /k start "Title" "D:/Documents and
Settings/sheltonm/Desktop/test.csv" &
- Tried adding quotes, still fails...

I have tried numerouse formatting changes, but cannot get this command
to work.
If I copy just <start "Title" "D:/Documents and
Settings/sheltonm/Desktop/test.csv"> directly to a command windows, it
works!
What am I missing????

Thanks.

[Gerald W. Lester]

Zoner wrote:
>
> I am trying to start excel from within tcl, but run into a problem when
> the path has spaces in it.
> I am running windows xp...
>
> 1: exec cmd.exe /k start $excelFileName &
> - This command works great if there are no spaces in the file name...
> - Example, c:/documents and settings/dirname/file.csv will fail...
> - If the path does have spaces, I will see a command window pop up with
> the
> filename as the title.

Try (in all cases):
exec cmd.exe /k start "\"[file nativename]\"" &

--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+

[Zoner]

Gerald W. Lester wrote:

>
> Try (in all cases):
> exec cmd.exe /k start "\"[file nativename]\"" &
>

Thanks for the tip, but
Nope - still doesn't do the trick...

I used: exec cmd.exe /k start "\"[file nativename $fileName]\"" &

I receive a windows error saying "Windows cannot find 'and'"...
This is due to the space between c:/documents and settings....

I compared the input and output of 'file nativename', and it does not
seem to change the string at all.

If you have any other ideas, keep em coming...

Thanks.

Matt

[Zoner]

Found an ugly workaround for this...
Essentially, I write the command to a .bat file in the current working
directory, and exec this file instead...
========
set fid [open temp.bat w]
puts $fid "start \"TITLE\" \"$fileName\""
close $fid
exec temp.bat &
file delete temp.bat
========
Please post if you have a better way...

[Ramon Ribó]

Hello,

This works for me:

eval exec [auto_execok start] "\"\"" [list $file] &

file can be either in UNIX (/) notation or WINDOWS (\) notation.

Windows, and specially DOS, can be somewhat stupid at times.

Regards,

Ramon Ribó

"Zoner" <matthew...@shaw.ca> escribió en el mensaje
news:1123126578.3...@o13g2000cwo.googlegroups.com...

[Donal K. Fellows]

Zoner wrote:
> 1: exec cmd.exe /k start $excelFileName &
> - This command works great if there are no spaces in the file name...
> - Example, c:/documents and settings/dirname/file.csv will fail...
> - If the path does have spaces, I will see a command window pop up with
> the
> filename as the title.

Easy to fix, provided the file already exists:

set filename {c:/documents and settings/dirname/file.csv}
set shortname [file attributes $filename -shortname]
exec cmd.exe /k start $shortname &

Some applications demand that you use backslashes; [file nativename]
will do that for you. If you are working with a file that doesn't yet
exist, use this (assuming the directory exists and the filename itself
doesn't have "bad" characters):
set shortname [file join \
[file attr [file dirname $filename] -shortname] \
[file tail $filename]]

Donal.

[Zoner]

Thanks guys...

Both of Ramon's and Donal's suggestions work, and much cleaner then my
bat file approach.

For Ramons suggestion, <eval exec [auto_execok start] "\"\"" [list
$file] &>, can you explain why the "\"\"" has to be there? I was
thinking this fit into the title argument of <start>, but it will not
work if there is text there. Also doesn't work if it is removed.

Thanks for the responses...

M

[Ramon Ribó]

Hello,

Sometimes, programming is trial and error, specially
with MSDOS and Windows...

Regards,

Ramon Ribó

"Zoner" <matthew...@shaw.ca> escribió en el mensaje

news:1123167736.4...@z14g2000cwz.googlegroups.com...

[davidh...@simplifiedlogic.com]

Try this:

package require tcom
::tcom::ref getobject d:/working/myexcelfile.xls

-- not sure if this will work 100% as documented - but you should
consider tcom as a method for doing this.

[Benjamin Riefenstahl]

Hi M,

"Zoner" writes:
> For Ramons suggestion, <eval exec [auto_execok start] "\"\"" [list
> $file] &>, can you explain why the "\"\"" has to be there? I was
> thinking this fit into the title argument of <start>,

It is. When you pass something in quotes as the first parameter to
the START command, it determines it is a title (see "START /?"). When
you do "exec start $file" and $file contains spaces, than [exec] will
add quotes to the filename and START actually gets and sees:

start "c:/path with spaces/filename with spaces"

> but it will not work if there is text there. Also doesn't work if it
> is removed.

If your text doesn't contain spaces (and isn't empty either), START
gets and sees:

start title-with-spaces "c:/path with spaces/filename with spaces"

where title-with-spaces doesn't have quotes, but the quotes are
actually required for a title in the view of START :-(. With the
above, START tries to execute the command "title-with-spaces", which
doesn't exist of course.

The underlying problem is that on DOS-style OSes each called program
does its command-line parsing on its own. Which leads to some quite
"interesting" differences. Having a variation of the [exec] command
that actually can construct *any* command-line (instead of doing one
particular type of formatting) is still an open todo for Tcl, I think
...

benny

[Ramon Ribó]

Hello,

> If your text doesn't contain spaces (and isn't empty either), START
> gets and sees:
>
> start title-with-spaces "c:/path with spaces/filename with spaces"
>
> where title-with-spaces doesn't have quotes, but the quotes are
> actually required for a title in the view of START :-(. With the
> above, START tries to execute the command "title-with-spaces", which
> doesn't exist of course.

Isn't it an ill defined specification?

Luckily, most of our work is performed in TCL, with lots of internal
coherence
(even the sub-languages like "expr" are nice to use).

Regards,

Ramon Ribó

"Benjamin Riefenstahl" <b.rief...@turtle-trading.net> escribió en el
mensaje news:m3acjwo...@seneca.benny.turtle-trading.net...

[Benjamin Riefenstahl]

Hi Ramon,

Benjamin Riefenstahl wrote:
>> start title-with-spaces "c:/path with spaces/filename with spaces"
>>
>> where title-with-spaces doesn't have quotes, but the quotes are
>> actually required for a title in the view of START :-(. With the
>> above, START tries to execute the command "title-with-spaces",
>> which doesn't exist of course.

"Ramon Ribó" writes:
> Isn't it an ill defined specification?

Well, it's not for me to defend Microsoft. But no, it's not "ill
defined" in the formal sense, I believe, it is unambiguous and clear:

START has two forms

START ?options? "title" cmd ?cmd-args?
START ?options? cmd ?cmd-args?

If the first argument to START after options is in quotes than the
first form is assumed. Otherwise the second form is assumed.

This specification just isn't a simulation of Unix shell semantics,
like most other console programs on Windows do it. And that is what
trips [exec].

Benjamin Riefenstahl wrote:
>> The underlying problem is that on DOS-style OSes each called
>> program does its command-line parsing on its own. Which leads to
>> some quite "interesting" differences.

benny

[Ramon Ribó]

Hi Benjamin,

> Well, it's not for me to defend Microsoft. But no, it's not "ill
> defined" in the formal sense, I believe, it is unambiguous and clear:
>
> START has two forms
>
> START ?options? "title" cmd ?cmd-args?
> START ?options? cmd ?cmd-args?
>
> If the first argument to START after options is in quotes than the
> first form is assumed. Otherwise the second form is assumed.
>
> This specification just isn't a simulation of Unix shell semantics,
> like most other console programs on Windows do it. And that is what
> trips [exec].

Well, it's not for me to attack Microsoft, but, altough defined in the
formal
sense, it leaves a lot of room to user errors:

MS-DOS permmits in all the commands. to write a file name with quotes
around the name or without. So, it is equivalent to do:

dir myfile
dir "myfile"

But if trying the same with start:

start myfile
start "myfile"

it gives very different results. Not very consistent, from my point of
view.

And all of this without considering "exec", just in a MSDOS window.

Regards,

Ramon

[Benjamin Riefenstahl]

Hi Ramon,

"Ramon Ribó" writes:
> MS-DOS permmits in all the commands. to write a file name with
> quotes around the name or without.

<nitpicking> We are not talking about MS-DOS, but about Windows, or
rather about CMD.EXE and other individual console programs usually
delivered with that Windows, right? </nitpicking>

There are similar ad-hoc rules for other commands, e.g. FIND (the
search string must be in quotes) or CD (the directory parameter can be
without quotes, even if it contains spaces).

> it gives very different results. Not very consistent, from my point
> of view.

Inconsistent between different commands. But still formally
well-defined for each command seen by itself. Which is what I thought
I meant to say ;-)

To repeat myself again:

> The underlying problem is that on DOS-style OSes each called program
> does its command-line parsing on its own. Which leads to some quite
> "interesting" differences.

This makes for inconsistencies especially when seen in contrast to
Unix shells. On Unix, interpretation of command syntax is done in one
program, the shell, so that it is necessarily uniform there. That is
as long as you stick to *one* shell. We have folks here regularly who
try Bash syntax in Tcl and wonder why that doesn't work.

benny