News flash: file names can have spaces in them!
Stephen Huntley
account for the possibility that a file name or pathname may have a
space in it.
Come on people! Pathnames can have spaces in them!
Even on Unix!
lvi...@yahoo.com
According to Stephen Huntley <blac...@usa.net>:
:The number one bug I see in other people's Tcl code is failure to
:account for the possibility that a file name or pathname may have a
:space in it.
:
:Come on people! Pathnames can have spaces in them!
Pathnames can have a lot of weird things in them.
However, for many developers, their systems _don't_ have those
weird characters in them, so they don't test for it. They would,
I suspect, consider such a thing an edge case - like running into
a disk out of space condition, etc.
Should all these be tested? Probably. Will they be? Unlikely.
So, if one has an edge condition when trying to run one of these programs,
what should they do?
Perhaps report the bug to the creator. Perhaps even submit a patch
back to the developer. Or move on to a program without that limitation.
--
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.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
Benjamin Riefenstahl
blac...@usa.net (Stephen Huntley) writes:
> The number one bug I see in other people's Tcl code is failure to
> account for the possibility that a file name or pathname may have a
> space in it.
Can you give an example? Unlike in shell-languages or Makefiles, in
Tcl you usually do not need to take an special measures to support
those file names in Tcl. So what kind of code do you see as a
"failure to account" here?
so long, benny
Mark G. Saye
So can:
widget names
variable names
array index names
namespace names
proc names
interp names
image names
named-font names
(probably many others I can't think of atm)
Unfortunately, as you've pointed out, many developers don't use such
'possibilities', and hence don't test for them, or even write code to
allow for them.
It's quite often the blinkered-vision use of 'eval' that causes
problems. For example (and a useless example):
proc config {W args} {
eval $W configure $args
}
would fail with a widget name W containing a space. A more robust version:
proc config (W args) {
eval [linsert $args 0 $W configure]
}
although some people may prefer the slightly more readable (but slightly
less efficient)
proc config (W args) {
eval [list $W configure] $args
}
Try using BWidgets with widget names containing spaces!
Another of my major annoyances is code that assumes a fixed install
location, and does not look for associated files based on the location
of the [info script] (normalized and symlink-resolved).
--
Mark G. Saye
markgsaye @ yahoo.com
Cameron Laird
.
.
The number one bug I see is people writing complicated
erroneous code in place of simpler implementations that
appreciate Tcl's semantics. Benjamin's right: "failure
to account for the possibility [of] ... a space" is usu-
ally a symptom of something deeper.
Or am I misinterpreting Benjamin?
I confess to infatuation with the rubric, "The number one
bug I see in other people's Tcl code." I can imagine a
successful weekly television game show on the topic. Any-
way, yes, I find mistakes instructive, and am trying to
figure out how to pursue this theme.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
Bryan Oakley
>
> Can you give an example? Unlike in shell-languages or Makefiles, in
> Tcl you usually do not need to take an special measures to support
> those file names in Tcl. So what kind of code do you see as a
> "failure to account" here?
entry .path -textvariable filename
...
eval exec $filename $args
.. then wait for the user to enter a filename like "c:/program files/..."
Gerald W. Lester
I agree with Brian about seeing this kind of thing all too often.
The problem here is failure to use list commands to build a script. The
correct code would read:
set cmd [concat [list exec $filename] $args]
eval $cmd
or better yet:
set status [catch $cmd msg]
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is
|
| Gerald...@cox.net | the man who is alive." -- Cervantes
|
+--------------------------------+---------------------------------------+
Jeff Hobbs
"Mark G. Saye" wrote in news:3EBBDAF3...@yahoo.com:
> proc config (W args) { eval [linsert $args 0 $W configure] }
>
> although some people may prefer the slightly more readable (but
> slightly less efficient)
>
> proc config (W args) { eval [list $W configure] $args }
These are actually equally efficient (the concat prior to eval invoke
also being pure-list aware).
> Try using BWidgets with widget names containing spaces!
You will actually find that more recent versions are much better, at
least in the widgets that I use ;^). I have been updating them as I
go along since I hate such unnecessary limitations.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Luciano
> The number one bug I see is people writing complicated
> erroneous code in place of simpler implementations that
> appreciate Tcl's semantics.
Ooops! I resent that. ;-)
It is a very natural phenomenon IMO. You're looking for the best way
to achieve something and get sort of entangled in your own spun web.
After some time, you may eventually get back to that, see things more
clearly and simplify your code. I've been working on my first Tcl/Tk
app. I am a newbie and only work on that in my spare time, so it's
been four months already! And I've rewritten it about four or five
times, always spotting something that can be made clearer and
simpler. I also made a somewhat long-winded application in PHP once.
Five months later, I got to rewrite it and got scared with the
incredible mess I had made. I spent three nights shaking the head at
what I had done and rewriting the whole stuff.
So I think it's part of the game, at least until you get *really*
proficient in the language, to the point at which you write in it
without ever having to stop to think how the hell you're going to say
this and that, as if it were just plain English in a chat board.
--
Luciano ES
<luci...@ggmmxx.nneett>
Santos, SP - Brasil
Luciano
Windows, that's "c:/Arquivos de programas/...", starting with A,
which makes it the first directory in the tree, therefore the default
target installation path of over 90% of all apps. I even have a
keyboard macro the replace it with "c:/progs/..."
But that's the useful aspect of "c:/program files/...". It it weren't
there, how much more code that disregards possible spaces in path
names would have gone by unnoticed?
Hmmm... I'm feeling starngely positive today. >:-\
--
Luciano ES
<luci...@ggmmxx.nneett>
Santos, SP - Brasil
<-quote-> **************************************************
ulis
> correct code would read:
>
> set cmd [concat [list exec $filename] $args]
> eval $cmd
Here Tcl is not very programer-friendly:
complicated code even though the intention is clear.
ulis
Benjamin Riefenstahl
Bryan Oakley <br...@bitmover.com> writes:
> entry .path -textvariable filename
> ...
> eval exec $filename $args
I'm inclined to call that "failure to use eval right". We know that
code like this fails with any string that contains spaces (or a number
of other special characters), not only filenames.
But OTOH, filenames probably *are* a primary candidate for this
particular problem, because programmers tend to forget that filenames
are just data, and can contain (almost) anything, as the OP pointed
out.
Other examples? Let's do a collection!
so long, benny
Kaitzschu
> Other examples? Let's do a collection!
News flash (to me): widget paths can't have dots in them!
Still doing that chat client, and wrote some code to create new toplevel
for private conversations. Everything worked fine until I accidently hit
wrong alias on the list and got
tk> Error: bad window path name ".privakisu."
me> Whatta #€@!..?
After a while I got it: alias was "kisu.." and my procedure tried to
create toplevel named ".priva$alias". Now, you don't do things like that,
do you. Bad scripter, shame on you!
Well, nothing to do, scrap the code since it is rather difficult to create
widgets with names different from aliases and still keep them in order and
logical.
Of course I could create "random" widget names and use a lookup table to
find a window for alias, but that would either suck a big time or fail
when "random" goes "pseudo".
If I used that lookup table I could use a toplevel counter (which
wouldn't go pseudo or ambiguous for a while, at least :) and create
toplevel .priva[incr counter]
with
set lookuptable($alias) $counter
but that just doesn't make the pain go away (hmmh.. actually it would take
the pain away with
proc lutn {alias} {
global lookuptable
return ".priva$lookuptable($alias)"
}
it takes just a whole lot of find-and-replaces).
There is also possibility to map dots to \x00 or \x04 (which aren't that
common characters in ascii feeds) and create a
toplevel .privakisu\x00\x00
but somehow that makes me feel odd (do you hear that chime that sounds
like "can't be compatible with anything"?)
I should had guessed it was too easy when it was so easy to do it :D
Gosh, I feel relieved (-relief sunken). Thank you for listening. Now I'll
go and code that toplevel counter, which will give me a nice feature: with
it I can redirect multiple aliases into single window.
Have a nice day.
--
-Kaitzschu ,-------------------------------.
| Kai Aho |
| http://www.kaitzschu.cjb.net/ |
`-------------------------------'
Gerald W. Lester
I disagree, it is just not what you are used to.
Follow the guideline that when building command use list operations so
they quote things for you. In the above we need to use concat, or a
foreach loop with lappend, because args is a list and concat will join
two list. Since we want filename to stay as one word and since it may
not be a proper list, we need to protect it by putting it inside of a
list command.
The other way to approach things is with the creative use of backslash.
The disadvantage is that you really have to think like the Tcl parser to
get it right the first time 100% of the time.
Long and short is each language is different, you have to learn the
language and use the language -- not try to shoehorn it into a language
you already know.
BTW, least I be accused of not knowing any other languages I believe the
last time I counted it was around 20 that I've programmed in enough to
say I know -- plus another dozen I've studied.
Darren New
> The problem here is failure to use list commands to build a script. The
> correct code would read:
>
> set cmd [concat [list exec $filename] $args]
> eval $cmd
So what's wrong with
eval exec [list $filename] $args
? Isn't that essentially the same thing, modulo performance perhaps?
(And worrying about the performance of arg parsing when you're going to
call [exec] seems a bit premature.)
I mean, the real problem is [eval] having unprotected arguments, not
spaces in file names. Once you look at every invocation of [eval] and
ask which arguments should be protected, you're pretty golden. (Plus you
have to start worrying about native / vs \ and stuff anyway, so...)
--
Darren New, San Diego CA USA (PST)
Church of Ladder Day Saints -
An obscure offshoot sect of the Frisbeetarians
Darren New
> I always hated that "c:/program files/..." path. In Brazilian
> Windows, that's "c:/Arquivos de programas/...", starting with A,
> which makes it the first directory in the tree, therefore the default
> target installation path of over 90% of all apps.
Isn't that a good thing?
> But that's the useful aspect of "c:/program files/...". It it weren't
> there, how much more code that disregards possible spaces in path
> names would have gone by unnoticed?
Actually, I suspect it's such a clunky name (along with
"c:\Documents and Settings\") to try to avoid walking on
already-existant directories when people upgrade the operating system.
That is, I can imagine a lot of names along the lines of "progs" that
people might have been using in DOS that MS didn't want to clobber by
installing Windows. (i.e., pick a bad name that nobody else would be
dumb enough to pick, and then we'll avoid naming conflicts. :-)
Gerald W. Lester
>
> Gerald W. Lester wrote:
> > The problem here is failure to use list commands to build a script. The
> > correct code would read:
> >
> > set cmd [concat [list exec $filename] $args]
> > eval $cmd
>
> So what's wrong with
> eval exec [list $filename] $args
> ? Isn't that essentially the same thing, modulo performance perhaps?
As is:
eval exec \$filename $args
> (And worrying about the performance of arg parsing when you're going to
> call [exec] seems a bit premature.)
>
> I mean, the real problem is [eval] having unprotected arguments, not
> spaces in file names. Once you look at every invocation of [eval] and
> ask which arguments should be protected, you're pretty golden. (Plus you
> have to start worrying about native / vs \ and stuff anyway, so...)
My point, which I guess I did not make very well, was that if list
commands are used to build scripts, then the arguments will always be
protected.
Arjen Markus
And how do we regret this! It is a true PITA on those systems that
actively encourage people to use them (or actively discourage people
not to use them), since spaces are now the most ambiguous character
in the whole UNICODE table.
Regards,
Arjen
se...@fishpool.com
>
> Follow the guideline that when building command use list operations so
> they quote things for you. In the above we need to use concat, or a
> foreach loop with lappend, because args is a list and concat will join
> two list. Since we want filename to stay as one word and since it may
> not be a proper list, we need to protect it by putting it inside of a
> list command.
The problem with this is that the [concat] and [lappend] manpages
don't give any hint of this behaviour. They say they build lists, but
it's not clearly defined anywhere that list functionality always ends
up with a list that can be passed to eval. You can't even say that
lists == strings that can be safely passed to eval as that's not even
true. This is just one way in which the mixing of list format and
quotability for [eval] is confusing.
Kaitzschu
> According to Kaitzschu:
> :
> :News flash (to me): widget paths can't have dots in them!
>
> Hmm - sounds like this is something that needs to be documented in a
> man page - have you submitted a bug report yet?
No, I haven't, since I don't consider this as a bug but a short-circuit in
my brain: no escaping/quoting/substituting in path names, what you type is
what you get (WYTIWYG), someone forgot that.
Besides, this has been documented: "Library Procedures - Tk_Name manual
page" says "Path names have a structure similar to file names in Unix but
with dots between elements instead of slashes" meaning "You don't use
dots in path names."
Maybe that isn't the first place where you look for that information, but
for most people it should be obvious you don't use delimiters in names -
and the rest shouldn't code at all :)
Ralf Fassel
| > set cmd [concat [list exec $filename] $args]
| > eval $cmd
|
| Here Tcl is not very programer-friendly: complicated code even
| though the intention is clear.
Is
eval exec \$filename $args
better?
R'
lvi...@yahoo.com
According to Kaitzschu <kait...@kaitzschu.cjb.net.plzdontspam.invalid>:
:Besides, this has been documented: "Library Procedures - Tk_Name manual
:page" says "Path names have a structure similar to file names in Unix but
:with dots between elements instead of slashes" meaning "You don't use
:dots in path names."
Hmm - this is one of those things that bug me in other languages. Have
to go to a C API man page to find out the naming scheme required in the
scripting language extension.
But then, one of the things that the current tcl/tk source distribution is
missing is an 'intro to tcl and tk'. Instead, we point people to one
of two in print books or various web sites.
Seems like something as simple as the intro to tcl and tk
that is over at http://www.tcl.tk/ would be worthwhile to include, just
so someone has some idea of where to start with the language.
lvi...@yahoo.com
According to <se...@fishpool.com>:
:Gerald W. Lester <gerald...@cox.net> wrote:
:> In the above we need to use concat, or a
:> foreach loop with lappend, because args is a list and concat will join
:> two list.
:The problem with this is that the [concat] and [lappend] manpages
:don't give any hint of this behaviour.
Any suggestions on improvements to the man page wording to provide a useful
hint ?
se...@fishpool.com
>
> According to <se...@fishpool.com>:
> :Gerald W. Lester <gerald...@cox.net> wrote:
> :> In the above we need to use concat, or a
> :> foreach loop with lappend, because args is a list and concat will join
> :> two list.
>
> :The problem with this is that the [concat] and [lappend] manpages
> :don't give any hint of this behaviour.
>
> Any suggestions on improvements to the man page wording to provide a useful
> hint ?
I don't know. Part of the problem is that this is a by-product of
list formation and generation of the optimised internal rep of lists.
That part of it is pretty difficult to explain. The alternative really
would be to clearly specify this with each list command that causes
this to happen.
[list] says the following:
"... and also so that eval may be used to execute the resulting list, with arg1
comprising the command's name and the other args comprising its
arguments."
If this applies to [concat] and [lappend], it should probably be copied
there too. So far I've just avoided those commands for the purpose
of quotation as the docs do not specify that behaviour.
Benjamin Riefenstahl
se...@fishpool.com writes:
> I don't know. Part of the problem is that this is a by-product of
> list formation and generation of the optimised internal rep of
> lists. That part of it is pretty difficult to explain.
Is it? Couldn't we just say on all pages for commands that create or
change lists:
The list that is created is in the same syntax as those lists
created by the [list] command, which see.
That should cover everything from the POV of a Tcl programmer.
so long, benny
se...@fishpool.com
> Hi,
>
>
> se...@fishpool.com writes:
>> I don't know. Part of the problem is that this is a by-product of
>> list formation and generation of the optimised internal rep of
>> lists. That part of it is pretty difficult to explain.
>
> Is it? Couldn't we just say on all pages for commands that create or
> change lists:
>
> The list that is created is in the same syntax as those lists
> created by the [list] command, which see.
Well valid list syntax doesn't require the quotation of those certain
characters. I think explicitness if always good and say that it includes
the quotation for use with [eval]
Benjamin Riefenstahl
> Benjamin Riefenstahl <Benjamin.R...@epost.de> wrote:
>> The list that is created is in the same syntax as those lists
>> created by the [list] command, which see.
se...@fishpool.com writes:
> Well valid list syntax doesn't require the quotation of those
> certain characters.
??? I didn't say "valid list syntax". If I read/hear "valid list
syntax" I think of all syntax that is legal as *input* to a Tcl
function.
I'm explicitly talking about lists *created* by Tcl. Those are all
the same and their properties (including the [eval] compatibility) are
spelled out in the [list] man page. The [list] man page naturally
doesn't talk about input but about output (there are not restrictions
on input). It says:
Braces and backslashes get added as necessary, so that the lindex
command may be used on the result to re-extract the original
arguments, and also so that eval may be used to execute the
resulting list, with arg1 comprising the command's name and the
other args comprising its arguments.
We could add this text to all pages of commands that create lists, but
I would think it's easier and even clearer, if we state it once and
all the other pages just refer to this one. The text on the [list]
page should probably be in its own paragraph, these syntactic points
are currently a bit mixed up with explanation of the semantic
difference with [concat].
> I think explicitness if always good and say that it includes the
> quotation for use with [eval]
Maybe we find a wording that is clearer than mine, as my proposal was
obviously not good enough. I'm not sure we should repeat the text
with the details in every related man page, though. I don't get the
feeling that the details are such an important feature for the other
functions (or such a problem), so that everybody needs to be reminded
of it all the time.
so long, benny
Donal K. Fellows
> The problem with this is that the [concat] and [lappend] manpages
> don't give any hint of this behaviour. They say they build lists, but
> it's not clearly defined anywhere that list functionality always ends
FWIW, that property is not enforced by [concat]. It is only true of the results
of concat if it was true of all the arguments to [concat]. But then [concat] is
a very odd beast indeed.
Donal.
--
"Everyone else is envisioning a future of 32-bit deep bump-mapped lizard-skin
scrollbars that adapt to the lusers mood by imperceptibly alpha-blending
through a range of chromatic combinations not repeating in 3^18 years. Needs
hardware acceleration, anaglyptic glasses, and 2 aspirin." -- Phil Ehrens
Donal K. Fellows
> And how do we regret this! It is a true PITA on those systems that
> actively encourage people to use them (or actively discourage people
> not to use them), since spaces are now the most ambiguous character
> in the whole UNICODE table.
I've seen filenames with ANSI escape sequences in them where doing an 'ls' on a
directory resulted in a scrolling message in the window title bar. By
comparison, spaces really are not that strange at all...
Donal (the purpose of users is to generate bad data.)
se...@fishpool.com
>
> I've seen filenames with ANSI escape sequences in them where doing an 'ls' on a
> directory resulted in a scrolling message in the window title bar. By
> comparison, spaces really are not that strange at all...
Hah, fantastic idea. Must make that into a compo for our next party :-)
jallan
>
> And how do we regret this! It is a true PITA on those systems that
> actively encourage people to use them (or actively discourage people
> not to use them), since spaces are now the most ambiguous character
> in the whole UNICODE table.
>
And hyphen-like characters are the second most ambiguous characters in
the whole Unicode table.
Jim Allan