Hi, As we all know well, we can write scripts like: #!/usr/bin/perl -w print "foo" and whatnot. i'd like to be able to write something like: #!/usr/local/ghc/bin/ghc main = do putStrLn "foo" and whatnot, even if I have to explicitely say something like: #!/usr/local/ghc/bin/ghc module Main(main) where main = do putStrLn "foo" it doesn't really matter. but i'd like to be able to write something like this, chmod +x it and be able to execute it, interpreted. i have *no* idea what the semantics of #!... is in shell scripts, so i don't know if it's easy or hard to hack something like this together, but if anyone has any pointer (or if anyone's done something like this before), please please please let me know. thanks! - hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On Tue, 6 Nov 2001, Hal Daume wrote:
Hi,
As we all know well, we can write scripts like:
#!/usr/bin/perl -w print "foo"
and whatnot. i'd like to be able to write something like:
#!/usr/local/ghc/bin/ghc main = do putStrLn "foo"
I don't know if you want ghc especially; if hugs is enough the standard distribution installs runhugs which you can cause to be invoked with the line #!/usr/bin/runhugs I do this with some scripts and, when there aren't any errors during either reading in or execution things work well. I seem to find that if something goes wrong I just end up with a line runhugs: without an actual error message. I seem to recall Alastair Reid saying it was something to do with the lack of vsnprintf (?) in a shared lib or something. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.
On Tue, 6 Nov 2001 00:48:12 GMT, Hal Daume wrote:
and whatnot. i'd like to be able to write something like:
#!/usr/local/ghc/bin/ghc main = do putStrLn "foo"
and whatnot, even if I have to explicitely say something like:
#!/usr/local/ghc/bin/ghc module Main(main) where main = do putStrLn "foo"
I guess you want to run ghci or hugs, not ghc. You should be able to implement this easily. I'm not running UNIX/Linux here, so I can't test it, but this should work fine just by specifying the correct executable path. The only problem I'm aware of is that the first line (the #! line) might be included in the input piped into the program, which means that you'll have to run it through a filter. But that filter should be very easy to make using awk or something like that. You could even make it in Haskell, if you want, and you could make it prepend the "module" header, too, for convenience. Salutaciones, JCAB email: jcab@roningames.com ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com
On Mon, 5 Nov 2001, Juan Carlos Arevalo-Baeza wrote:
correct executable path. The only problem I'm aware of is that the first line (the #! line) might be included in the input piped into the program, which means that you'll have to run it through a filter.
according to http://www.uni-ulm.de/~s_smasch/various/shebang/ the input isn't piped but rather the name of the file is passed. In addition to ensuring the run program doesn't misinterpret the #! line the current directory is also kept where it is even if the script is being invoked by ../../script.hs (for example) so you either need to somehow pass include path arguments or have all your imports being absolute paths. HTH, ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.
On Tue, 6 Nov 2001 02:46:54 +0000 (GMT), D. Tweed wrote:
On Mon, 5 Nov 2001, Juan Carlos Arevalo-Baeza wrote:
correct executable path. The only problem I'm aware of is that the first line (the #! line) might be included in the input piped into the program, which means that you'll have to run it through a filter.
according to http://www.uni-ulm.de/~s_smasch/various/shebang/ the input isn't piped but rather the name of the file is passed.
Ouch! :) My bad, then.
In addition to ensuring the run program doesn't misinterpret the #! line the current directory is also kept where it is even if the script is being invoked by ../../script.hs (for example) so you either need to somehow pass include path arguments or have all your imports being absolute paths.
Now, this sounds very wrong to me. The interpreter/compiler should first look for imported modules in the directory where the current source file was found, not in whatever directory is current in the OS. It's much more consistent and reliable that way, eliminating dependencies on arbitrary OS-related values. IMHO, of course. I'd suggest compiler/interpreter vendors to make sure they, at least, allow this kind of behavior by using command-line switches or something. If they haven't done it yet, that is. Is this behavior specified in the Report? And what's the rationale for using it? I mean, not even GCC uses this kind of thing (in fact the C/C++ standards specify the proper search order for #includes). Salutaciones, JCAB email: jcab@roningames.com ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com
On Mon, 5 Nov 2001, Juan Carlos Arevalo-Baeza wrote:
current directory is also kept where it is even if the script is being invoked by ../../script.hs (for example) so you either need to somehow pass include path arguments or have all your imports being absolute paths.
Now, this sounds very wrong to me. The interpreter/compiler should first look for imported modules in the directory where the current source file was found, not in whatever directory is current in the OS. It's much more consistent and reliable that way, eliminating dependencies on arbitrary OS-related values.
That makes a lot of sense. Unfortunately, (to quote Tom Cruise from Mission: Impossible") "Oh, it's much worse than you think." The name that gets passed to the interpreter is `the top-level name of the script', so if /home/tweed/bin/myscript.hs is actually a symlink to /home/tweed/src/haskell/myscript.hs and I invoke it from /home/tweed/odd/ with ../bin/myscript.hs, what gets passed is "../bin/myscript.hs" (at least under bash on linux). So whilst the interpreter could in principle get to thinking it should look in /home/tweed/bin/ for imports by applying "../bin/myscript.hs" to $cwd, AFAICS there's no way it can get hold of the directory /home/tweed/src/haskell. When I figured this out I just decided that the method that would lead to least banging of my head against wall was just to absolute path any imports of non standard distribution code.
Is this behavior specified in the Report? And what's the rationale for using it? I mean, not even GCC uses this kind of thing (in fact the C/C++ standards specify the proper search order for #includes).
I guess unix symlinks make handling imports automatically impossible, so at least on some platforms handling things automatically can't be specified by the report. ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.
On Tue, 6 Nov 2001 03:42:51 +0000 (GMT), D. Tweed wrote:
The name that gets passed to the interpreter is `the top-level name of the script', so if /home/tweed/bin/myscript.hs is actually a symlink to /home/tweed/src/haskell/myscript.hs and I invoke it from /home/tweed/odd/ with ../bin/myscript.hs, what gets passed is "../bin/myscript.hs" (at least under bash on linux). So whilst the interpreter could in principle get to thinking it should look in /home/tweed/bin/ for imports by applying "../bin/myscript.hs" to $cwd, AFAICS there's no way it can get hold of the directory /home/tweed/src/haskell. When I figured this out I just decided that the method that would lead to least banging of my head against wall was just to absolute path any imports of non standard distribution code.
Well... I still disagree. From my point of view, it could be argued the order in which directories are searched for modules, but I don't think there's any need to exclude any directories. The interpreter should search not just the current directory, but also the directory of the file where the source was found. At least. I'd even add subdirectories "./modules/" (or "./haskell.modules/" or something like that) of both of them, just for added value :) IMHO, there's no reason not to search a reasonable place for a needed piece of information. It's like Koenig lookups in C++. It just makes sense to look there, just in case.
Is this behavior specified in the Report? And what's the rationale for using it? I mean, not even GCC uses this kind of thing (in fact the C/C++ standards specify the proper search order for #includes).
I guess unix symlinks make handling imports automatically impossible, so at least on some platforms handling things automatically can't be specified by the report.
Yes, I understand that this can make matters a little more convoluted. I'm just advocating for flexibility here. You lose a bit of predictability in exchange for much flexibility. Maybe that's a price you don't want to pay, but I sure would. And if not standard, this makes sense, at least, as a toggleable switch. Anyway... This is not my war. Just my opinion. O:-) Salutaciones, JCAB email: jcab@roningames.com ICQ: 101728263 The Rumblings are back: http://www.JCABs-Rumblings.com
[Suggest moving any followup to haskell-cafe to avoid boring people] On Mon, 5 Nov 2001, Juan Carlos Arevalo-Baeza wrote:
On Tue, 6 Nov 2001 03:42:51 +0000 (GMT), D. Tweed wrote:
The name that gets passed to the interpreter is `the top-level name of the script', so if /home/tweed/bin/myscript.hs is actually a symlink to /home/tweed/src/haskell/myscript.hs and I invoke it from /home/tweed/odd/ with ../bin/myscript.hs, what gets passed is "../bin/myscript.hs" (at least under bash on linux). So whilst the interpreter could in principle get to thinking it should look in /home/tweed/bin/ for imports by applying "../bin/myscript.hs" to $cwd, AFAICS there's no way it can get hold of the directory /home/tweed/src/haskell. When I figured this out I just decided that the method that would lead to least banging of my head against wall was just to absolute path any imports of non standard distribution code.
Well... I still disagree. From my point of view, it could be argued the order in which directories are searched for modules, but I don't think there's any need to exclude any directories. The interpreter should search not just the current directory, but also the directory of the file where the source was found. At least. I'd even add subdirectories "./modules/" (or "./haskell.modules/" or something like that) of both of them, just for added value :)
IMHO, there's no reason not to search a reasonable place for a needed piece of information. It's like Koenig lookups in C++. It just makes sense to look there, just in case.
I entirely agree it would be great if this could be done. However it seems that runhugs at least _doesn't_ do it, and I suspect that may be because it technically can't. I never use unix hardlinks myself (only symlinks), but IIRC if you've got two or more hardlinks to a file there's no way to find out from the filesystem what the directories of the other links to the file are, so if you invoke via a hardlink then it's really difficult to do automatic imports correctly. (I may be wrong about this.) Incidentally, I do have a setup with symlinks as described above; it's not just hypothetical.
Anyway... This is not my war. Just my opinion. O:-)
Oh, you make very good points, I just suspect that it `can't be done'. I'd love to be proved wrong :-) ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.
participants (3)
-
D. Tweed -
Hal Daume -
Juan Carlos Arevalo-Baeza