How the heck do I pass an argument to a program being run by 'exec'
that starts with a '<' character?

ie. How do I make it so that (argv[1] == "<hello>")

Thanks,
Dan

puts [exec echo '[lindex $argv 0]']

Greets,
Martin

You can't.  exec is just plain too "oversophisticated" for this task.

There are some workarounds, such as exec'ing  sh -c with a string,
where all sh's metacharacters are explicitly backslash-escaped,
but that is platform-dependent and sucks.
Another one is, to execute some wrapper-prog, that undoes certain
tricks to get through exec (like for example single-quotes).

There have also been discussions about it in the past, and
suggestions for alternative commands <http://mini.net/tcl/1353>,
but the problem didn't yet occur often enough persuade anyone
able to do it to implement it.

In other words: Of those who had these itches, none knew how to
  scratch them, and of those who know, none had these itches.

--
Nichts ist schlimmer als zu wissen, wie das Unheil sich entwickelt,
 und voll Ohnmacht zusehn muessen - das macht mich voellig krank...
              -- (Musical Elisabeth; "Die Schatten werden laenger")

  exec /bin/sh -c {exec /the/program '<hello>'}
  # Note that the word after the -c is a Bourne Shell script, not Tcl.

Donal.
--

"Give a concrete proposal, rather than just handwaving. Everything's obvious
 and easy if you don't have to do it yourself."                  -- Darren New

:In other words: Of those who had these itches, none knew how to
:  scratch them, and of those who know, none had these itches.

It would probably be easier - or at least more likely to result in a
solution - for those with itches to learn how to scratch them than for
those who know how to find time to scratch someone else's itch...
--
The Tenth Annual Tcl/Tk Conference <URL: http://www.tcl.tk/community/tcl2003 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

--
Nichts ist schlimmer als zu wissen, wie das Unheil sich entwickelt,
 und voll Ohnmacht zusehn muessen - das macht mich voellig krank...
              -- (Musical Elisabeth; "Die Schatten werden laenger")

(*) Of course, part of this is luck. If someone named a file '<foo' and
I passed that as an argument to exec I would have a problem.

Whenever some proposals are discussed whose inclusion might (under
 very unlucky circumstances) cause different behaviour, then
 these (low) probabilities of failure are usually considered a
 big blocking point.
 E.g. who would accept adding a special argument "--" to  exec or
 eval given that "--" might be a valid command. But everyone seems
 to accept, that '<hello' just won't ever occur as a valid argument
 to pass through to some exec'd program.

--
Nichts ist schlimmer als zu wissen, wie das Unheil sich entwickelt,
 und voll Ohnmacht zusehn muessen - das macht mich voellig krank...
              -- (Musical Elisabeth; "Die Schatten werden laenger")

--
Darren New, San Diego CA USA (PST)
Things to be thankful for, #187:
  There is no Chinese tradition of changing from
  shoes to slippers to get off an escalator.

something like
 exec >redir1 <redir2 $magic foo <hello>
with $magic being some not yet specified  magic-string,
with the same purpose as "--" for commands accepting
optional dash-preceded options.

$magic could be  "<>><<>" or "<>"  or anything currently bogus.
Whatever it is, I'm sure, that the (inevitable) "ugliness" or even
slightest chance of an incompatibility would thwart such a change
in the eyes of those who deny the fact that the current behaviour
is much worse (for completely excluding strings starting with
certain prefixes to be passed to the command).

--
Nichts ist schlimmer als zu wissen, wie das Unheil sich entwickelt,
 und voll Ohnmacht zusehn muessen - das macht mich voellig krank...
              -- (Musical Elisabeth; "Die Schatten werden laenger")

Also there are currently no TIPS in existence to address this.
Do you know of a TIP rejected?

Just wondering what the sore spot is all about.

Roy

:Still, I'm really surprised how this issue can be of
:non-itch nature to even *anyone* actually using exec
:in any but most trivial ways. Some things I'll likely
:never understand.

I make certain I never create files with special characters in them...

--
The Tenth Annual Tcl/Tk Conference <URL: http://www.tcl.tk/community/tcl2003 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

:

::Still, I'm really surprised how this issue can be of
::non-itch nature to even *anyone* actually using exec
::in any but most trivial ways. Some things I'll likely
::never understand.
:
:I make certain I never create files with special characters in them...

I forgot to mention - the tcl code I write is for myself.  That makes things
easier for me.

Certainly I understand someone else having an issue here.  
--
The Tenth Annual Tcl/Tk Conference <URL: http://www.tcl.tk/community/tcl2003 >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

exec >somefile -- echo >somefile2

would print '>somefile2' into 'somefile'. However:

exec >somefile rm -- -YOURFILE-.txt

would pass -- to rm.

Then you could argue that only incompatibility would be to call a
command called '--', to which you would not specify any path. I doubt if
any system has a command with such a name :)

I'd really suggest looking into this as it is a very dangerous bug - it
can be used in any script exec'ing anything to write arbitrary text to a
file. It is really {*filter*}.

--
WK

set x " <hi there>"
puts [exec /bin/echo $x]

by the way, if I specify echo, I get 'not found'. How do I make Tcl to
find what is in my path?

Thanks,
Siva