special characters in exec command argument

[Kevin Rodgers]

I need to pass a string to an external program via exec, but the string
contains several special characters (spaces, double quotes, and angle
brackets):

<!DOCTYPE CASEKEY2 PUBLIC "-//Carswell//DTD Case Keying2//EN">

Simply putting that in double quotes and escaping the embedded double
quotes with backslash doesn't work, because exec insists on interpreting
the angle brackets as redirection operators. And for some reason,
escaping the angle brackets with a backslash doesn't prevent them from
being interpreted that way; it takes 2 backslashes each:

"\\<!DOCTYPE CASEKEY2 PUBLIC \"-//Carswell//DTD Case Keying2//EN\"\\>"

as confirmed by

puts [exec echo "\<this is \"not\" a file!\>"]
and
puts [exec echo "\\<this is \"not\" a file!\\>"]

But that causes backslash characters to be included in the string
that's passed to the external program. (I don't understand why not,
but using echo to test the string doesn't reveal that.)

So what is the right way to pass a string that contains these special
characters to an external program via exec?

Thanks,
--
Kevin Rodgers <kev...@ihs.com> Lead Software Engineer
Information Handling Services Electronic Systems Development
15 Inverness Way East, M/S A201 GO BUFFS!
Englewood CO 80112-5776 USA 1 303 397 2807[voice]/2244[fax]

Sent via Deja.com http://www.deja.com/
Before you buy.

[Cameron Laird]

In article <87a4es$1a$1...@nnrp1.deja.com>, Kevin Rodgers <kev...@ihs.com> wrote:
>I need to pass a string to an external program via exec, but the string
>contains several special characters (spaces, double quotes, and angle
>brackets):
>
> <!DOCTYPE CASEKEY2 PUBLIC "-//Carswell//DTD Case Keying2//EN">
>
>Simply putting that in double quotes and escaping the embedded double
>quotes with backslash doesn't work, because exec insists on interpreting
>the angle brackets as redirection operators. And for some reason,
>escaping the angle brackets with a backslash doesn't prevent them from
>being interpreted that way; it takes 2 backslashes each:
>
> "\\<!DOCTYPE CASEKEY2 PUBLIC \"-//Carswell//DTD Case Keying2//EN\"\\>"
>
>as confirmed by
>
> puts [exec echo "\<this is \"not\" a file!\>"]
>and
> puts [exec echo "\\<this is \"not\" a file!\\>"]
>
>But that causes backslash characters to be included in the string
>that's passed to the external program. (I don't understand why not,
>but using echo to test the string doesn't reveal that.)
>
>So what is the right way to pass a string that contains these special
>characters to an external program via exec?

.
.
.
How does
set complicated_string \
{<!DOCTYPE CASEKEY2 PUBLIC "-//Carswell//DTD Case Keying2//EN">}
set result [exec sh -c "echo '$complicated_string'"]
work for you?
--

Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html

[Frederic BONNET]

Hi,

Cameron Laird wrote:
>
> In article <87a4es$1a$1...@nnrp1.deja.com>, Kevin Rodgers <kev...@ihs.com> wrote:
> >I need to pass a string to an external program via exec, but the string
> >contains several special characters (spaces, double quotes, and angle
> >brackets):

[...]

>
> How does
> set complicated_string \
> {<!DOCTYPE CASEKEY2 PUBLIC "-//Carswell//DTD Case Keying2//EN">}
> set result [exec sh -c "echo '$complicated_string'"]
> work for you?

This works indeed but only on Unix. The problem is that there is no way to
escape angle brackets in exec arguments. Maybe this should be fixed. One should
for instance be allowed to escape angle brackets with backslashes or something
else (like triple <>'s that would be substituted to one). But this may introduce
potential incompatibilities. Maybe a flag -noredirect to disable io redirection?

See you, Fred
--
Frédéric BONNET frederi...@ciril.fr
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain

[Alexandre Ferrieux]

Frederic BONNET wrote:
>
> The problem is that there is no way to
> escape angle brackets in exec arguments. Maybe this should be fixed.

Yup, this (as well as the similar "|" issue a few days ago) is a
consequence of the fact that exec's command-and-args lists and
exec-specific-options (<>|) list are flatly merged. It is a design
mistake: a fully safe method would be to add just one level of depth:
pass the cmd-args lists as standalone arguments:

safer_exec {ps axuwww} | {grep foobar} | {grep -v grep} > baz 2>@
stderr

Of course we can add this primitive (along with the similar [open "|.."
- oh my) , but the orthogonality of the language will suffer. Unless, of
course, when we do that long-needed API rationalization, we clearly tag
the old one as 'deprecated'...

Joys of backwards compatibility vs. evolution :)

-Alex

[Kevin Rodgers]

cla...@starbase.neosoft.com (Cameron Laird) wrote:
> How does
> set complicated_string \
> {<!DOCTYPE CASEKEY2 PUBLIC "-//Carswell//DTD Case Keying2//EN">}
> set result [exec sh -c "echo '$complicated_string'"]
> work for you?

It works great -- thanks!

But in an effort to make it platform independent, I tried this:

if [info exists env(SHELL)] {
set shell $env(SHELL)
if [string match /bin/*sh $env(SHELL)] {
set shell_switch "-c"
} else {
set shell_switch "/c"
}
} elseif [info exists env(COMSPEC)] {
set shell $env(COMSPEC)
set shell_switch "/c"
} else {
set shell /bin/sh
set shell_switch "-c"
}

It works fine on Unix, but on Windows NT (a platform with which I have
no experience) it reports:

Cannot execute "C:\WINDOWS\COMMAND.COM"

But I can run commands like this from a DOS shell on that same machine:

C:\WINDOWS\COMMAND.COM /c dir

So what determines whether a command (like COMMAND.COM) can be exec'ed
on Windows NT? What should I be using for a shell on that platform
instead of COMMAND.COM?

[David Cuthbert]

Kevin Rodgers wrote:
> It works fine on Unix, but on Windows NT (a platform with which I have
> no experience) it reports:
>
> Cannot execute "C:\WINDOWS\COMMAND.COM"

This is puzzling. The command-line shell on Windows NT is cmd.exe, not
command.com (the system has both, but for reasons that aren't clear to me
you want to stay away from command.com). The full path is
$env(windir)/system32/cmd.exe.

But your script looks correct! In fact, it runs as expected on my machine
-- it calls c:\winnt\system32\cmd.exe. (In fact, c:\winnt\command.com
doesn't exist here; that, too, is under ...\system32).

Are you or some other program overriding COMSPEC or SHELL? That's the only
thing I can think of off the top of my head.

Also, some interesting results from tclsh:
% exec c:/winnt/system32/cmd.exe /c echo hello
hello
% exec c:/winnt/system32/cmd.exe /c "echo hello"
hello

% exec c:/winnt/system32/command.com /c echo hello
hello
% exec c:/winnt/system32/command.com /c "echo hello"
Bad command or file name

[Kevin Rodgers]

David Cuthbert <da...@kanga.org> wrote:
> Kevin Rodgers wrote:
> > It works fine on Unix, but on Windows NT (a platform with which I
have
> > no experience) it reports:
> >
> > Cannot execute "C:\WINDOWS\COMMAND.COM"
>
> This is puzzling. The command-line shell on Windows NT is cmd.exe,
not
> command.com (the system has both, but for reasons that aren't clear to
me
> you want to stay away from command.com). The full path is
> $env(windir)/system32/cmd.exe.

Argh, I'm sorry. I told you I was unfamiliar with NT. It turns out that
I am so unfamiliar with it that I didn't even realize that the machine
is actually running Windows 98. Presumably that explains why COMSPEC is
set to C:\WINDOWS\COMMAND.COM on it.

> But your script looks correct! In fact, it runs as expected on my
machine
> -- it calls c:\winnt\system32\cmd.exe. (In fact, c:\winnt\command.com
> doesn't exist here; that, too, is under ...\system32).

So COMSPEC must be set to c:\winnt\system32\cmd.exe on your machine,
right?

> Are you or some other program overriding COMSPEC or SHELL? That's the
only
> thing I can think of off the top of my head.

Not that I can see.

> Also, some interesting results from tclsh:
> % exec c:/winnt/system32/cmd.exe /c echo hello
> hello
> % exec c:/winnt/system32/cmd.exe /c "echo hello"
> hello

Good.

> % exec c:/winnt/system32/command.com /c echo hello
> hello
> % exec c:/winnt/system32/command.com /c "echo hello"
> Bad command or file name

Bad, indeed.

And the ugly: I've just been informed that this must run on Windows 95,
Windows 98, and Windows NT. Is there any hope of that, or should I just
distribute 3 different versions (4, if you count Unix)?

Thanks,

[Don Porter]

>> % exec c:/winnt/system32/command.com /c echo hello
>> hello
>> % exec c:/winnt/system32/command.com /c "echo hello"
>> Bad command or file name

Kevin Rodgers <kev...@ihs.com> wrote:
> And the ugly: I've just been informed that this must run on Windows 95,
> Windows 98, and Windows NT. Is there any hope of that, or should I just
> distribute 3 different versions (4, if you count Unix)?

Don't try to solve all the cross-platform stuff yourself. Tcl has
already licked that problem. Use the tools it provides.

Let me know if the following doesn't work everywhere:

eval exec [auto_execok echo] [list hello]

--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|