Re: What is wrong with this simple command?



On Aug 31, 2:33 pm, Andreas Leitgeb <a...@xxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
Had he posted the response (surely more than 4k, perhaps more than hundred
lines) untrimmed, I for one surely wouldn't have bothered to answer.  I leave
it to others to decide if that would have been a pro or con, and consequentially
whether the snipping was helpful or not ;-)

I think GWL's post was much more concise and intelligible than mine,
but just didn't address the basic difference between shell and script
execution. That is really all I was trying to get at or add to the
discussion. I didn't and I don't think GWL needed too see anything
more than the two commands and the error message to guess at the
cause: [set data ...] never completed so the variable data didn't
exist.

There is one other issue in this particular case, which might be fixed
in the current Tcl, but I'm not sure it can be fixed.

When you execute a OS shell commmand (like [cat ...], the process
passes through the [unknown] command, which has a [catch]. Once this
happens it can be somewhat difficult to track down errors if/when the
found command returns an error. It is probably better to avoid this
route as it is a very expensive method for executing shell commands.

Anyway, I took the question, which seems very reasonable to me: how
could the data variable not exist, I just set it. And the answer is
because you are at an interactive shell which allows you to continue,
pretty much like every shell I've ever used.

The one which I run into every year or so is similar. I source a file,
know that it has been sourced. I place logging statements in the file
to verify the fact. Yet the procs defined in the file don't exist! But
it always turns out to be caused by defining procs without a
leading ::. I think the confusion derives from the seeming total
illogic of the situation. In such circumstances you simply refuse to
believe the error messages and start looking for an enormous bug. I
mean, after all, a bug has to be pretty big to make a variable
evaporate all by itself.

As far as posting lots of data, in essence I agree that it makes my
eyes glaze over. OTHO, a bug is first of all defined by unexpected
behavior. If you only present a subset of this unexpected behavior you
are falling into the trap of thinking you understand something (or
maybe you are just trying to be nice). This contradicts the definition
of a bug: something unexpected. The most difficult step in problem
solving is rejecting what you think you know. Sometimes that requires
posting lots of stuff on clt and finding out there is a simple
answer.

I still maintain that the hardest bug to find is one which does not
exist. That is, the behavior is unexpected, but only because you
expect something else.
.



Relevant Pages

  • Re: Make command
    ... when I run these commands from the shell (after CD to correct ... I'm getting the error message ... A better way is to install checkinstall. ...
    (alt.os.linux.suse)
  • Re: Make command
    ... when I run these commands from the shell (after CD to correct ... I'm getting the error message ... I'm logging in as root ...
    (alt.os.linux.suse)
  • Re: [opensuse] Ran out of disk space
    ... Jim Flanagan wrote: ... Maybe that was bug #338009, even though in this bug the file is not _that_ big. ... open a shell and do the following: ... For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx ...
    (SuSE)
  • Bash-3.1 released
    ... This is the first maintenance release for the third major release of bash. ... A few new features ... and the `nocasematch' shell option are the most notable. ... Fixed a bug that caused a DEBUG trap to overwrite a command string that's ...
    (comp.os.linux.announce)
  • Bash-3.1 released
    ... This is the first maintenance release for the third major release of bash. ... A few new features ... and the `nocasematch' shell option are the most notable. ... Fixed a bug that caused a DEBUG trap to overwrite a command string that's ...
    (comp.unix.shell)