Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^6: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

by dragonchild (Archbishop)
on Jan 10, 2008 at 02:05 UTC ( [id://661541]=note: print w/replies, xml ) Need Help??


in reply to Re^5: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK
in thread Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

Ah. Wow. Maybe I'm just brainwashed, but letting program changes persist just seems like a recipe for disaster. *shrugs*

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re^6: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

Replies are listed 'Best First'.
Re^7: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK
by BrowserUk (Patriarch) on Jan 10, 2008 at 03:20 UTC
    letting program changes persist just seems like a recipe for disaster.

    Hm. Maybe I gave a false impression? They only persist, for that instance of the shell, and only until that shell instance terminates. And by that judgement, isn't the following also a potentially disasterous recipe?

    c:\test>perl -de1 Loading DB routines from perl5db.pl version 1.3 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 1 DB<1> $x = 12345 DB<2> print $x 12345 DB<3>

    Because replace DB<1> with c:\test> and it is exactly analogous. And in any case, the behaviour is easily altered to your preferred option:

    C:\test>path PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\T... C:\test>cmd /c "set path=a load of junk here && path" PATH=a load of junk here C:\test>path PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBEM;C:\T...

    Or when invoking a bat file you can avoid it changing the current shell instance by explicitly starting a new instance of the shell to run it as in:

    C:\test>type junk.bat set test=this is the value set inside the .bat file c:\test>start /b junk.bat c:\test>set test=this is the value set inside the .bat file c:\test>set test Environment variable test not defined

    So either behaviour is easily available. And here's yet another way to choose the required behaviour:

    c:\test>type junk.bat set test1=this persists setlocal set test2=this does not persist endlocal set test3=and this persists also c:\test>set | find "test" c:\test>junk c:\test>set test1=this persists c:\test>setlocal c:\test>set test2=this does not persist c:\test>endlocal c:\test>set test3=and this persists also c:\test>set | find "test" test1=this persists test3=and this persists also

    We could argue till we are blue in the face about which is the correct behaviour, but the reality is that these are two different systems with two different 'default' behaviours. So assuming that they are the same, or complaining that they are not is futile.

    I could also argue that the Win32 behaviour is more flexible because it gives you the choice, and that there are some very definite uses for it's default behaviour. But I'm guessing you probably won't read down this far, and they would fall on deaf ears even if you do.

    And that in a nutshell is my major problem with efforts like cygwin and Strawberry Perl.

    • cygwin, as effective as it is at doing what it sets out to do, is for all the word like fitting a set of handlbars to a family estate car and expecting it to handle like a motorbike.

      If you want a motorbike, buy one.

    • Strawberry Perl worries me exactly because it appears to have been successful in pursuading a number of key Perl contribtors to use it in preference to AS.

      Whilst I acknowledge that it has brought some benefits to Win32 users, it has set the precedent that it is becoming the defacto target for win32 development effort when most users live in the AS world. That makes for a world where many incompatibilities remain and some will not, by definition cannot, be addressed.

      It also means that by "dodging the bullet" of fixing the AS port, it removes the possibility for allowing Perl full access to some of the uniquely Win32 technologies that could really benefit Win32 Perl users.

    The attempt is to make win32 look and behave like *nix so that *nix people are more comfortable and can pretend that they do not sully themselves. But in that attempt, they create more problems than they resolve. And, by the by, throw away the potential for some really good stuff.

    Just as it is unlikely that I could ever get up to speed on *nix to rival the hardcore *nix Perl developers. It is, with rare exception, unreasonable to expect that many of them will get up to speed on win32 development sufficiently to exploit the full potential of Perl on Win32. The only solution I see is for pairs of people to get together from both sides to drive things forward to successfully exploit the potential from both sides. But that requires feedback.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Strawberry has that feedback. Both xdg and Alias are that rare bird that straddles the Win32/*nix fence. Alias, in particular, has helped drive a lot of the Perl-on-Win32 stuff.

      As for the discussion of these behaviors ... Yes, it is a default behavior. And, with a bit of fiddling, you can get the Win32-default behavior to occur in *nix. The parent process has to be the one to do that kind of decision - the child can only offer up options. And, yes, I have occasionally wanted that kind of behavior and been annoyed at the stuff I had to do to get it to dwim.

      But, discussing default behaviors does have a good side to it and that is to help understand why different defaults were chosen so that when we are in the position of determining default behaviors, we make better choices. For example, a few jobs back we were putting up a completely new app with a lot of complex behaviors available. We spent weeks working through the various defaults we could set and trying to figure out which was the "best" default behavior (for some value of "best"). Defaults are probably one of the hardest things to get right. Apple spends an inordinate amount of time on it and is praised for elegance. Linux spends almost no time on it and has a reputation for being overwhelming; Ubuntu has spent more time on it and is a very easy-to-use distro. Win32 ... I have mixed feelings. :-)


      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        shaken or stirred?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://661541]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chanting in the Monastery: (4)
As of 2024-06-18 23:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.