Am Sonntag 21 Februar 2010 18:20:43 schrieb Artyom Kazak:

...

Enclose it in double quotes (perhaps single quotes would also work)

No, I want my program to work the same way as UNIX "echo" does. Without any double quotes.

Okay, what about "If you absolutely positively want all the rest of the options in a command line to go to the program (and not the RTS), use a ––RTS." $ ./prog +RTS --RTS +RTS ? (BTW, enclosing in quotes doesn't work anyway if the argument consists *only* of "+RTS", same as with echo, echo "-e" doesn't output '-e' either).

On 21 February 2010 18:58, Artyom Kazak wrote:

So, if I type "./prog +RTS --RTS +RTS", the output will be "+RTS". But I want the output to be equal to the input IN ALL CASES, without any quotes, additional options, etc. I want all the command line to go to my program. How can I do it? (The only way I know now - hacking the GHC. If there are no other ways, I'll do it.)

You might be able to get somewhere by writing a custom "main" function in C and linking it in. According to http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html if a lib specified with the -l option during compilation contains a "main", that will be used in preference to the one from HSrts. You could presumably just extend argv with the "+RTS" "--RTS" entries and then call into the one from HSrts, so this might even be quite easy. Cheers, Max

Supply a fix for the problem, and it will probably get included. There has probably been little demand for this feature so far. -- Lennart On Sun, Feb 21, 2010 at 10:21 PM, Ben Millwood wrote:

On Sun, Feb 21, 2010 at 7:10 PM, Max Bolingbroke wrote:

...

You might be able to get somewhere by writing a custom "main" function in C and linking it in. According to http://haskell.org/ghc/docs/latest/html/users_guide/options-phases.html if a lib specified with the -l option during compilation contains a "main", that will be used in preference to the one from HSrts.

I think the neater way of doing this would be to use the FFI, with a foreign export declaration making your haskell main available to a wrapper C file, which would then initialise the RTS with a slightly-modified argc and argv. See http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html for details on how to do that.

I also think it's strange, though, that adding RTS hooks is not optional. GHC should support some method of disabling them, in my opinion. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2010/2/22 Ivan Miljenovic :

On 22 February 2010 10:55, Lennart Augustsson wrote:

...

Supply a fix for the problem, and it will probably get included. There has probably been little demand for this feature so far.

But it is a little bit weird where if you have an application that you release into production (which, admittedly, I've never done), then end users are able to fiddle with settings which they shouldnt' really touch (though there's not really that much that I can see that they'd be able to do wrong with just RTS settings...).

Isn't the same situation with java, or even with any application using some config files, or with dynamic libraries ? Cheers, Thu

On Sun, Feb 21, 2010 at 1:58 PM, Artyom Kazak wrote:

So, if I type "./prog +RTS --RTS +RTS", the output will be "+RTS". But I want the output to be equal to the input IN ALL CASES, without any quotes, additional options, etc. I want all the command line to go to my program. How can I do it? (The only way I know now - hacking the GHC. If there are no other ways, I'll do it.)

How about a wrapper script? Something like, #! /usr/bin/env bash ./prog --RTS $* Just use that as the front-end to your Haskell program. Anthony

On Feb 22, 2010, at 03:36 , Roman Cheplyaka wrote:

* Anthony Cowley [2010-02-21 14:15:00-0500]

...

#! /usr/bin/env bash ./prog --RTS $*

./prog --RTS "$@"

Otherwise it will work wrong if arguments contain quoted field separators (e.g. spaces).

#! /bin/sh ./prog --RTS ${1+"$@"} The longer specification above should work with whatever /bin/sh is around, whether it's Solaris /sbin/sh, FreeBSD's sh, general Linux bash, Debian/Ubuntu dash, etc. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Wed, Feb 24, 2010 at 07:18, Roman Cheplyaka wrote:

* Brandon S. Allbery KF8NH [2010-02-24 00:02:12-0500]

...

On Feb 22, 2010, at 03:36 , Roman Cheplyaka wrote:

...

* Anthony Cowley [2010-02-21 14:15:00-0500]

...

#! /usr/bin/env bash ./prog --RTS $*

./prog --RTS "$@"

Otherwise it will work wrong if arguments contain quoted field separators (e.g. spaces).

  #! /bin/sh   ./prog --RTS ${1+"$@"}

The longer specification above should work with whatever /bin/sh is around, whether it's Solaris /sbin/sh, FreeBSD's sh, general Linux bash, Debian/Ubuntu dash, etc.

Are you referring to some Solaris shell bug?

Under POSIX these constructs seem to be equivalent. "If there are no positional parameters, the expansion of '@' shall generate zero fields, even when '@' is double-quoted."

I believe he's referring to the following bit (taken from bash's man page): * Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, it expands to a single word with the value of each parameter separated by the first character of the IFS special variable. That is, "$*" is equivalent to "$1c$2c...", where c is the first character of the value of the IFS variable. If IFS is unset, the parameters are separated by spaces. If IFS is null, the parameters are joined without intervening separators. @ Expands to the positional parameters, starting from one. When the expansion occurs within double quotes, each parameter expands to a separate word. That is, "$@" is equivalent to "$1" "$2" ... If the double-quoted expansion occurs within a word, the expansion of the first parameter is joined with the beginning part of the original word, and the expansion of the last parameter is joined with the last part of the original word. When there are no positional parameters, "$@" and $@ expand to nothing (i.e., they are removed). /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

On Feb 24, 2010, at 05:19 , Roman Cheplyaka wrote:

Well, this agrees with POSIX. So still I don't see the difference between "$@" and ${1+"$@"}.

The difference is that Unix /bin/sh predates POSIX, and on systems that usefully support a notion of backward compatibility (nostly commercial, because (1) they have installed user bases that predate POSIX and (2) they actually think it's worthwhile to support said user bases) /bin/sh uses the traditional behavior that "$@" expands to "" if there are no arguments. (This is "stupid" but consistent, another concept that seems to have been thrown to the wolves.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Feb 24, 2010, at 02:18 , Roman Cheplyaka wrote:

...

#! /bin/sh ./prog --RTS ${1+"$@"}

The longer specification above should work with whatever /bin/sh is around, whether it's Solaris /sbin/sh, FreeBSD's sh, general Linux bash, Debian/Ubuntu dash, etc.

Are you referring to some Solaris shell bug?

Under POSIX these constructs seem to be equivalent. "If there are no positional parameters, the expansion of '@' shall generate zero fields, even when '@' is double-quoted."

s/Solaris/most commercial Unixes/ because making /bin/sh POSIX would break too many things (unlike Linux/*BSD, they have to consider backward compatibility; a concept that Linux in particular seems not to comprehend). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

* Artyom Kazak [2010-02-24 10:23:07+0200]

2010/2/24 Brandon S. Allbery KF8NH :

...

On Feb 22, 2010, at 03:36 , Roman Cheplyaka wrote:

...

* Anthony Cowley [2010-02-21 14:15:00-0500]

...

#! /usr/bin/env bash ./prog --RTS $*

 ./prog --RTS "$@"

Otherwise it will work wrong if arguments contain quoted field separators (e.g. spaces).

 #! /bin/sh  ./prog --RTS ${1+"$@"}

The longer specification above should work with whatever /bin/sh is around, whether it's Solaris /sbin/sh, FreeBSD's sh, general Linux bash, Debian/Ubuntu dash, etc.

And with Windows, of course :) Haskell is cross-platform, isn't it?

Haskell is a language, it does not have any notion of platform. It has several implementations, which may or may not be cross-platform. (OP asked specifically about ghc, which supports a number of platforms, including Windows.) Here we talk not about ghc itself, but about POSIX shell interpreter, which is available on every POSIX-compliant operating system. Windows (out of the box) lacks implementation of POSIX shell. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain