If I assign a new value to $0, I find it is truncated.
$ cat test-dollar0.rb
puts $0
str = “/foo” * 20
puts str.size
$0 = str
puts $0
puts $0.size
$ ruby test-dollar0.rb
test-dollar0.rb
80
/foo/foo/foo/foo/foo
20
$ ln -s test-dollar0.rb td.rb
$ ruby td.rb
td.rb
80
/foo/foo/f
10
In 1.8.6 I can get around this by $0.replace(’…’), which sets $0 to
any string I like. However this doesn’t work in 1.8.7 or 1.9, because in
those versions $0 is a frozen string.
Any suggestions for how to fix this? The application is that I want to
start launcher program A, which in turn loads program B. Program B may
be a Test::Unit test suite, and Test::Unit gets the test suite name from
$0. So I either end up with the test suite having the name of program A
(which is wrong), or a truncated version of program B’s name (which is
also wrong)
Thanks,
Brian.
On 16.05.2009 15:03, Brian C. wrote:
$ ruby test-dollar0.rb
10
also wrong)
Modifying $0 seems a bit hackish to me. Can’t you just set the name
explicitly?
Kind regards
robert
On May 16, 2009, at 6:03, Brian C. [email protected] wrote:
If I assign a new value to $0, I find it is truncated.
This behavior is OS dependent, try a different OS.
Hi,
In message “Re: $0 is truncated”
on Sat, 16 May 2009 22:03:36 +0900, Brian C.
[email protected] writes:
|If I assign a new value to $0, I find it is truncated.
Platform info please. On some platforms, changing program name (as
seen from ps for example) is limited to the original size. We cannot
relax OS limitation.
matz.
Hi,
In message “Re: $0 is truncated”
on Sun, 17 May 2009 02:22:45 +0900, Brian C.
[email protected] writes:
|This is under Linux (Ubuntu Hardy).
|
|Yes, I’m aware that maybe setproctitle has limits, but it’s also useful
|to set $0 to a longer Ruby string (even if that’s not fully reflecting
|in the proctitle), because another piece of Ruby code in the same
|process may be testing the value of $0.
|
|In ruby 1.8.6, I can use $0.replace(“any long string”) which works just
|fine for setting $0 - presumably not setting the proctitle of course.
|But this stopped working in 1.8.7/1.9 because $0 is frozen.
OK, choose either from the following.
[ ] it’s OK (for you) that $0 is not corresponding to process name
read by ps etc. at all, i.e. if you set $0 longer than the
limit, $0 will be updated but the proc title will not.
[ ] it’s OK (for you) that $0 is not always corresponding to process
name read by ps etc.; in this case if you set $0 longer than the
limit, $0 will be updated but the proc title will be truncated to
the limit.
[ ] it’s important for you to just update the $0, so that $0 string
should not be frozen to allow replacing. When you replace $0
string, you’d take the responsibility.
matz.
Yukihiro M. wrote:
Hi,
In message “Re: $0 is truncated”
on Sat, 16 May 2009 22:03:36 +0900, Brian C.
[email protected] writes:
|If I assign a new value to $0, I find it is truncated.
Platform info please. On some platforms, changing program name (as
seen from ps for example) is limited to the original size. We cannot
relax OS limitation.
This is under Linux (Ubuntu Hardy).
Yes, I’m aware that maybe setproctitle has limits, but it’s also useful
to set $0 to a longer Ruby string (even if that’s not fully reflecting
in the proctitle), because another piece of Ruby code in the same
process may be testing the value of $0.
In ruby 1.8.6, I can use $0.replace(“any long string”) which works just
fine for setting $0 - presumably not setting the proctitle of course.
But this stopped working in 1.8.7/1.9 because $0 is frozen.
Regards,
Brian.
On May 16, 2009, at 13:36, Brian C. [email protected] wrote:
originally, and only changed it to $0.replace(…) as a workaround.
In this case, why is it important that you check $0? Why not use any
other global variable?
Yukihiro M. wrote:
[ ] it’s OK (for you) that $0 is not always corresponding to process
name read by ps etc.; in this case if you set $0 longer than the
limit, $0 will be updated but the proc title will be truncated to
the limit.
Yes, that would be my preferred option.
I don’t mind whether $0 is frozen. Actually, I wrote $0 = …
originally, and only changed it to $0.replace(…) as a workaround.
Regards,
Brian.
Hi,
At Sun, 17 May 2009 05:36:39 +0900,
Brian C. wrote in [ruby-talk:336729]:
I don’t mind whether $0 is frozen. Actually, I wrote $0 = …
originally, and only changed it to $0.replace(…) as a workaround.
You can find a hint in ext/extmk.rb.
$progname = $0
alias $PROGRAM_NAME $0
alias $0 $progname
trace_var(:$0) {|val| $PROGRAM_NAME = val} # update for ps
Nobuyoshi N. wrote:
Hi,
At Sun, 17 May 2009 05:36:39 +0900,
Brian C. wrote in [ruby-talk:336729]:
I don’t mind whether $0 is frozen. Actually, I wrote $0 = …
originally, and only changed it to $0.replace(…) as a workaround.
You can find a hint in ext/extmk.rb.
$progname = $0
alias $PROGRAM_NAME $0
alias $0 $progname
trace_var(:$0) {|val| $PROGRAM_NAME = val} # update for ps
Wow, that’s a trick I wouldn’t have thought of in a hundred years 
Thank you.
On May 16, 6:24 pm, Eric H. [email protected] wrote:
In this case, why is it important that you check $0? Why not use any
other global variable?
I’m guessing it has to do with the bit in the original post where he
said “Test::Unit gets the test suite name from $0”.