> On Nov 8, 2017, at 9:17 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> DrRacket tries not to interfere with programs in a detectable way.
Hmm ... so if DrRacket adopts a different set of environment variables from
command-line `racket` — which I assume is the correct and just policy — isn't
that naturally going to lead to detectable differences, for a program that
depends on those variables?
For instance, it seems odd that DrRacket agrees with `racket` on #"USER" and
#"LOGNAME" being #"MB", but #"PATH" is totally different.
In DrRacket it's #"/usr/bin:/bin:/usr/sbin:/sbin", but I don't know where that
Moreover, suppose I had a racket shell script that depended on my user "PATH".
I don't see how I could test that program in DrRacket without dropping a
`(putenv PATH "my_user_path")` at the top.
> On Nov 8, 2017, at 8:48 AM, John Clements <cleme...@brinckerhoff.org> wrote:
> IIRC, Mac has an apologetic moue towards unix-y things here: I believe
> there’s a special place in your home directory … or maybe it’s in
> ~/Library/Preferences, which would …
We are in a maze of twisty little passages, all alike.
> Is there something more general that you want to test for DrRacket ---
> some effect on the execution environment that might be due to DrRacket
> or some other tool/configuration? If so, it could make sense to set up
> some way of communicating that to a program.
In this case I was trying to configure a web servlet to run in differently when
launched from DrRacket (in terms of its port and servlet-path) to better
approximate Apache / htaccess conditions that exist on the live web server.
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.