case of sub! not working 
Author Message
 case of sub! not working

Hi,

Here's an interesting phenomenon:


irb(main):001:0> ENV['PATH']
=> "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin:/usr/kerberos/bin"
irb(main):002:0> ENV['PATH'].sub!(%r(:/usr/kerberos/bin), '')
=> "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin"
irb(main):003:0> ENV['PATH']
=> "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin:/usr/kerberos/bin"
irb(main):004:0> puts VERSION
1.8.0
=> nil

Why doesn't the sub! work in line 002? It returns the correct answer,
but ENV['PATH'] is not modified in-place. I've verified that the
behaviour is the same in 1.6, too.

Ian
--
Ian Macdonald               | If little green men land in your back yard,
System Administrator        | hide any little green women you've got in

http://www.*-*-*.com/      | Anarchist's Almanac"
                            |



Sat, 19 Nov 2005 09:11:07 GMT  
 case of sub! not working

Quote:

> Hi,

> Here's an interesting phenomenon:


> irb(main):001:0> ENV['PATH']
> => "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin:/usr/kerberos/bin"
> irb(main):002:0> ENV['PATH'].sub!(%r(:/usr/kerberos/bin), '')
> => "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin"
> irb(main):003:0> ENV['PATH']
> => "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin:/usr/kerberos/bin"
> irb(main):004:0> puts VERSION
> 1.8.0
> => nil

> Why doesn't the sub! work in line 002? It returns the correct answer,
> but ENV['PATH'] is not modified in-place. I've verified that the
> behaviour is the same in 1.6, too.

ENV is not exactly a Hash, but a singleton that behaves kinda like one.
Apparently, one difference is that ENV[key] returns a copy of the value.
(In hash.c, you can verify this by seeing that rb_f_getenv() calls
rb_str_new2 or rb_tainted_str_new2 to generate the return value.)

So I guess you have to do something like

   ENV['PATH'] = ENV['PATH'].sub(...)



Sat, 19 Nov 2005 09:21:43 GMT  
 case of sub! not working

Quote:

> >Here's an interesting phenomenon:


> >irb(main):001:0> ENV['PATH']
> >=> "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin:/usr/kerberos/bin"
> >irb(main):002:0> ENV['PATH'].sub!(%r(:/usr/kerberos/bin), '')
> >=> "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin"
> >irb(main):003:0> ENV['PATH']
> >=> "/usr/bin:/bin:/usr/X11R6/bin:/usr/pubsw/bin:/usr/kerberos/bin"
> >irb(main):004:0> puts VERSION
> >1.8.0
> >=> nil

> >Why doesn't the sub! work in line 002? It returns the correct answer,
> >but ENV['PATH'] is not modified in-place. I've verified that the
> >behaviour is the same in 1.6, too.

> ENV is not exactly a Hash, but a singleton that behaves kinda like one.
> Apparently, one difference is that ENV[key] returns a copy of the value.
> (In hash.c, you can verify this by seeing that rb_f_getenv() calls
> rb_str_new2 or rb_tainted_str_new2 to generate the return value.)

Thanks for the explanation. This definitely violates the principle of
least surprise, however, and I consider it a bug. At the very least, it
should go into the documentation, including the FAQ.

Quote:
> So I guess you have to do something like

>   ENV['PATH'] = ENV['PATH'].sub(...)

Yes, that's what I came up with, too.

Ian
--
Ian Macdonald               | Harrisberger's Fourth Law of the Lab:
System Administrator        | Experience is directly proportional to the

http://www.caliban.org      |
                            |



Sat, 19 Nov 2005 11:21:00 GMT  
 case of sub! not working

Quote:
----- Original Message -----


Sent: Monday, June 02, 2003 10:21 PM
Subject: Re: case of sub! not working

> Thanks for the explanation. This definitely violates the principle of
> least surprise, however, and I consider it a bug. At the very least, it
> should go into the documentation, including the FAQ.

A surprise but not a bug. Things that interact with
the outside world sometimes work that way in Ruby.
A similar example is cgi.params which is hash-like
but is not a hash. (Of course, it's changed somewhat
since I started playing with it.)

Hal



Sat, 19 Nov 2005 14:49:33 GMT  
 case of sub! not working
Hi,

In message "Re: case of sub! not working"

|> ENV is not exactly a Hash, but a singleton that behaves kinda like one.
|> Apparently, one difference is that ENV[key] returns a copy of the value.
|> (In hash.c, you can verify this by seeing that rb_f_getenv() calls
|> rb_str_new2 or rb_tainted_str_new2 to generate the return value.)
|
|Thanks for the explanation. This definitely violates the principle of
|least surprise, however, and I consider it a bug. At the very least, it
|should go into the documentation, including the FAQ.

Never say that.  You had two assumptions

  * sub! to modify the receiver in-place

  * when you modify the string from ENV in-place, the value of the
    environment variable changes automagically.

The former assumption is valid, the latter is not.  And it costs very
much to satisfy your expectation.

But I agree with putting it in the FAQ, for people fall into the same
trap.

                                                        matz.



Sat, 19 Nov 2005 15:20:21 GMT  
 case of sub! not working

Quote:
> Hi,

> In message "Re: case of sub! not working"

> |> ENV is not exactly a Hash, but a singleton that behaves kinda like one.
> |> Apparently, one difference is that ENV[key] returns a copy of the
value.
> |> (In hash.c, you can verify this by seeing that rb_f_getenv() calls
> |> rb_str_new2 or rb_tainted_str_new2 to generate the return value.)
> |
> |Thanks for the explanation. This definitely violates the principle of
> |least surprise, however, and I consider it a bug. At the very least, it
> |should go into the documentation, including the FAQ.

> Never say that.  You had two assumptions

>   * sub! to modify the receiver in-place

>   * when you modify the string from ENV in-place, the value of the
>     environment variable changes automagically.

> The former assumption is valid, the latter is not.  And it costs very
> much to satisfy your expectation.

> But I agree with putting it in the FAQ, for people fall into the same
> trap.

how about making the interpreter running a $ENV.freeze at the beginning of
the program?
if the variable can't be modified (somehow), it'd be more intuitive if it's
read-only, or do i miss something?

emmanuel



Sat, 19 Nov 2005 15:35:11 GMT  
 case of sub! not working
..

Quote:
> how about making the interpreter running a $ENV.freeze at the beginning of
> the program?
> if the variable can't be modified (somehow), it'd be more intuitive if it's
> read-only, or do i miss something?

ENV['foo'] = 'bar'

p `echo $foo`



Sat, 19 Nov 2005 15:41:52 GMT  
 case of sub! not working

Quote:

> ...
> > how about making the interpreter running a $ENV.freeze at the beginning
of
> > the program?
> > if the variable can't be modified (somehow), it'd be more intuitive if
it's
> > read-only, or do i miss something?

> ENV['foo'] = 'bar'

> p `echo $foo`

wow, nice :O)

didn't know that...



Sat, 19 Nov 2005 15:51:49 GMT  
 case of sub! not working
Hi,

In message "Re: case of sub! not working"

|how about making the interpreter running a $ENV.freeze at the beginning of
|the program?

Do you mean freezing strings from ENV?  Hmm, maybe.

                                                        matz.



Sat, 19 Nov 2005 17:43:44 GMT  
 case of sub! not working

Quote:
> Thanks for the explanation. This definitely violates the principle
> of
> least surprise, however, and I consider it a bug. At the very
> least, it
> should go into the documentation, including the FAQ.

Can someone mention *why* this is like it is?  (ENV keys are copies
so modifications are lost.)

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



Sat, 19 Nov 2005 21:15:59 GMT  
 case of sub! not working

Quote:
----- Original Message -----


Sent: Tuesday, June 03, 2003 8:15 AM
Subject: Re: case of sub! not working

> > Thanks for the explanation. This definitely violates the principle
> > of
> > least surprise, however, and I consider it a bug. At the very
> > least, it
> > should go into the documentation, including the FAQ.

> Can someone mention *why* this is like it is?  (ENV keys are copies
> so modifications are lost.)

I'll take a stab at it. I can't promise that
what I say is correct.

The illusion of ENV being a simple hash is a
good one. But remember that when you get/set
environment variables, ultimately you are
calling getenv/setenv or some equivalent.

It's one thing to do an ENV[x] = y, as []=
is a method invoked on ENV. We can trap the
change and call setenv.

But if ENV[x] refers to a string, and I change
that string... then ENV itself hasn't changed.
In fact, for an in-place change, even the
object id of the string hasn't changed.

To accomplish something like ENV[x].sub! working
intuitively, we would have to monitor every
string object referenced by ENV and watch to see
when any of them was changed.

Perhaps possible but impractical and inefficient.

Hal



Sun, 20 Nov 2005 03:29:31 GMT  
 case of sub! not working

Quote:
> I'll take a stab at it. I can't promise that
> what I say is correct.

I gotcha.  Ruby is doing this to avoid having to track the actual
changes to the string (outside of changes to ENV), and/or dealing
with copy-on-write semantics.

Interesting; thanks.

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com



Sun, 20 Nov 2005 03:39:44 GMT  
 case of sub! not working
Saluton!

* Emmanuel Touzery; 2003-06-03, 11:06 UTC:

Quote:
> > ENV['foo'] = 'bar'

> > p `echo $foo`

Let me add the result of the above code:

"bar\n"

Quote:
> wow, nice :O)

> didn't know that...

Please make sure you really do understand the whole issue:

$ ruby -e "ENV['foo'] = 'bar'"; echo "'$foo'"
''

The change is not persistent but limited to the environment your Ruby
script runs in - which is *not* the environment the script is started
from but discarded after run. As a result the above code only has
limited use. But that's a Linux/Unix FAQ, no Ruby FAQ ...

Gis,

Josef 'Jupp' Schugt



Sun, 20 Nov 2005 06:18:05 GMT  
 case of sub! not working

Quote:
> > I'll take a stab at it. I can't promise that
> > what I say is correct.

> I gotcha.  Ruby is doing this to avoid having to track the actual
> changes to the string (outside of changes to ENV), and/or dealing
> with copy-on-write semantics.

> Interesting; thanks.

In my program, however, I would have been quite happy to have sub! just
modify the copy of ENV['PATH'] that it had made, as I wanted to modify
the path that would be used to find the location of a binary I was about
to open with popen. I wasn't trying to modify the outside environment,
just that of my script and any of it children.

Ian
--
Ian Macdonald               | Breeding rabbits is a hare raising
System Administrator        | experience.

http://www.caliban.org      |
                            |



Sun, 20 Nov 2005 09:14:28 GMT  
 case of sub! not working

Quote:


> > > I'll take a stab at it. I can't promise that
> > > what I say is correct.

> > I gotcha.  Ruby is doing this to avoid having to track the actual
> > changes to the string (outside of changes to ENV), and/or dealing
> > with copy-on-write semantics.

> > Interesting; thanks.

> In my program, however, I would have been quite happy to have sub! just
> modify the copy of ENV['PATH'] that it had made, as I wanted to modify
> the path that would be used to find the location of a binary I was about
> to open with popen. I wasn't trying to modify the outside environment,
> just that of my script and any of it children.

Which again needs the setenv() call to actually alter the value in the
environment. and it did modify the copy of ENV['PATH'] it made, but it
didn't propagate it back to ENV :)

ENV['bla'] = "banzai"
`echo $bla` # <-- banzai\n
x=ENV['bla'].sub!(/banzai/, "ayaken") # here the copy is modified, result => x
`echo #{x}` # <-- ayaken\n <<- see, it did modify the copy
`echo $bla` # <-- banzai\n <<- but no setenv() call.

-martin



Sun, 20 Nov 2005 09:25:58 GMT  
 
 [ 26 post ]  Go to page: [1] [2]

 Relevant Pages 

1. FP o/i sub vi not working

2. Borges in Apache not work in my case.

3. trace not working in global, and upvar cases

4. Case insensitive re.sub()

5. Upper case / Lower case I'm a lost case

6. CASE vs case vs Case...

7. Does not work with TPS but works with DBF

8. 5.2 Network application works with 95, does not work with 98

9. Does the Autosave works in Excel , if not how to make it work in my program

10. Work library not same as current working library

11. REALdatabase not null and primary key not working

12. ExtenalInterface sub only works if ENVY edition

 

 
Powered by phpBB® Forum Software