The /\000.*$/ shouldn’t be there.
The code looks like
def test_rubicon
file_name = nil
p $0
start = File.dirname($0) # BOOM null is not understood.
for base in [“.”, “language”]
In the changelog there seems to have been many changes
recently to the dir handling. I wonder if that could be
the reason?
I tried to make a small piece of code which could reproduce
the problem. But the problem seems only to be provoked when I do
a test_all.
ruby a.rb
“a.rb”
cat a.rb
require ‘b’
class C
include M
end
C.new.m
cat b.rb
module M
def m
p $0
end
end
Today is devoted to make a working proof of concept, which can provoke the problem. Though I hope someone is able to
recognize the problem before then.
lib/test/unit/ui/console/testrunner.rb (test_started): show test
name via $0.
ATT: Nobu
I think its a bad idea to use global variables for this.
Wouldn’t it be better to have a instance variable with such info.
For instance ‘@test_name’… would be lot better.
···
On Sat, 17 Apr 2004 15:46:01 +0200, Simon Strandgaard wrote:
On Sat, 17 Apr 2004 15:20:09 +0200, Simon Strandgaard wrote:
I have just upgraded to 1.9 16-apr-2004 from 1.9 7-apr-2004.
One of my testsuites is no longer working, which worked
with the previous version. It shows up that $0 is cluttered
up.
Ok… I have tracked it down. The problem seems to be located in
Test::Unit.
Apparently there is also a problem with print,
as indicated by Decoux. Where \0 is interpreted differently
on linux, compared to sparc, freebsd.
The other problem is that Test::Unit recently has
begun showing the test-name via the $0 variable.
Which is bad. May I propose to introduce a instance
variable ‘@test_name’ for that, instead of touching
the $0 global variable.
lib/test/unit/ui/console/testrunner.rb (test_started): show test
name via $0.
ATT: Nobu
I think its a bad idea to use global variables for this.
Wouldn’t it be better to have a instance variable with such info.
For instance ‘@test_name’… would be lot better.
I mailed Nathaniel Talbott about it:
Well, I think I understand why it was changed (although I didn’t make
the change)… if you set the $0 variable, then ps, top, etc., will
display that value when you do a process listing. I know I’ve found
that to be handy for some processes myself. So it seems the serious
issue might be the weird output you’re ending up with, as opposed to
setting $0. But Nobu’s really the one to make the final call on it, as
he put that change in.
Now it makes much more sense… However I still wish
that $0 would be untouched by Test::Unit.
···
On Sat, 17 Apr 2004 16:10:19 +0200, Simon Strandgaard wrote:
I guess \0 slips through ‘p’, and is outputted/interpreted by the
system console. I think ‘p’ should do escaping to prevent such
hiding of information (on linux).
Isn’t it something which should be fixed?
···
On Sun, 18 Apr 2004 00:38:48 +0900, ts wrote:
Apparently there is also a problem with print,
Probably I’m wrong but this has nothing to do with print …
I guess \0 slips through 'p', and is outputted/interpreted by the
system console. I think 'p' should do escaping to prevent such
hiding of information (on linux).
$0 is a special variable and linux and *BSD have some differences ...
I guess \0 slips through ‘p’, and is outputted/interpreted by the
system console. I think ‘p’ should do escaping to prevent such
hiding of information (on linux).
$0 is a special variable and linux and *BSD have some differences …