In message <201005042150.o44lolls015...@f7.net>, Karl Berry writes:
>Aside from that: the FSF will also accept a copyright disclaimer,
>putting changes in the public domain. So if that's your preference (as
>I think I saw in another message), it is fine.
Ahh, that would work nicely.
My proposal
In message <4be03f2d.7090...@redhat.com>, Eric Blake writes:
>As original author, you get to choose the license that will be used
>within gnulib. I see nothing wrong with you declaring that the
>setproctitle module is LGPLv2+.
Ahh, okay.
That said, the more I look at this, the less sure I am tha
In message , "Alfred M. Szmidt" writes:
>If the FSF is the copyright holder, then there is no (legal) need to
>ask the original author about permission to relicense the work. It
>might be a nice thing to do, but if the original author says no for
>some reason, the FSF can still relicense the work;
In message <87r5lr51hh@meyering.net>, Jim Meyering writes:
>Can you simply declare the copyright to be LGPLv2+?
>Many modules are already LGPLv2+ (see modules/*).
I could if I were just releasing the code myself, but if the FSF needs
a copyright assignment, does that not imply that I no longer
In message <87hbmo5fzq@meyering.net>, Jim Meyering writes:
>Thanks for volunteering. Yes, this would be useful.
>There are many implementations floating around.
There are indeed a ton.
>Can you assign copyright to the FSF?
I think I can. There is some ambiguity about the IP agreement at $d
Is there any interest in attempting to provide a moderately portable
setproctitle()? (I think it would be reasonable for it to, on some
systems, simply fail to do anything...)
Apparently, this functionality exists in "util-linux-ng", and sendmail has
an implementation that works on Linux, but it
In message <200901212258.n0lmwqx07...@f7.net>, Karl Berry writes:
>I am surprised. I thought 0 was supposed to be a valid null pointer in
>all contexts, without casting.
0 is a null pointer constant. In a context where the language anticipates
a pointer, a null pointer constant becomes a null po
In message <[EMAIL PROTECTED]>, Eric Blake writes:
>Quotes won't help; the shell then tries to evaluate the command 'unset FOO'
>with no arguments, because there is no reason to do IFS splitting.
Doh.
>But this works, using an intermediate variable, so that IFS splitting still
>occurs:
>$ /bin
In message <[EMAIL PROTECTED]>, Eric Blake writes:
>Peter Seebach seebs.net> writes:
>
>>
>> In regards to worries about "unset FOO" not working if FOO is not set:
>>
>> ${FOO+unset FOO}
>>
>> Is this crazy or clever? It works in So
In message <[EMAIL PROTECTED]>, Eric Blake writes:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Tom G. Christensen on 9/21/2008 2:30 PM:
>> cc-3316 cc: ERROR File = handler-unix.c, Line = 490
>> The expression must be a pointer to a complete object type.
>>
>> ss.ss_sp =
In message <[EMAIL PROTECTED]>, "James
Youngman" writes:
>On Wed, Sep 17, 2008 at 5:12 AM, Peter Seebach <[EMAIL PROTECTED]> wrote:
>
>> set -- args
>
>Hmm, I certainly have a habit of doing this instead:
>
>set x blablablablabla
>shift
>
>H
In regards to worries about "unset FOO" not working if FOO is not set:
${FOO+unset FOO}
Is this crazy or clever? It works in Solaris sh. (I know, in most cases,
it's sufficient to just empty the variable, but sometimes it'd be nice to
be able to distinguish between empty and unset.)
-s
In message <[EMAIL PROTECTED]>, Bruno Haible writes:
>If you want to contribute shell script functions to gnulib, we would need some
>kind of "linker" for shell scripts: A tool which combines a set of shell
>script fragments, each defining a number of functions, and a "main" script,
>into a complet
In message <[EMAIL PROTECTED]>, Ralf Wildenhues writes:
>> I enclose func_select below. Weaknesses:
>> 1. Newline after prompt. (Solving this portably seemed like too much work.)
>Grab the settings of ECHO_C, ECHO_N, ECHO_T from Autoconf, and use them.
ECHO_T? New on me.
I could probably do
In message <[EMAIL PROTECTED]>, Ralf Wildenhues writes:
>> [EMAIL PROTECTED] (Peter Seebach) wrote:
>> > I've been getting utterly stunned pretty regularly throughout. The only
>> > system I've found so far, other than embedded systems (hi, busybox!), whi
This came from a pair of sources; my work on portable shell, and the discovery
that glibc's tzselect "requires ksh".
Originally, I thought "there's no way you could implement select in a shell
which doesn't have it, because it's a control structure". And indeed, you
can't.
But you can implement
In message <[EMAIL PROTECTED]>, Ralf Wildenhues writes:
>Quoting the Autoconf manual:
>| `unset'
>| In some nonconforming shells (e.g., Bash 2.05a), `unset FOO' fails
>| when `FOO' is not set. Also, Bash 2.01 mishandles `unset MAIL' in
>| some cases and dumps core.
>So look for sys
Hi! Gary Vaughn pointed me at gnulib for portability experts.
I've been working on some portable shell scripting material. I'm trying to
track down the details of a couple of "some systems can't..." comments from
the Autoconf documentation, because I haven't been able to find any such
systems.
18 matches
Mail list logo
