Hi Ben,
Thanks for this analysis.
> Default handling of SIGPIPE
> ---
>
> b...@blp:~/tmp(0)$ strace -o foo -f bash
> b...@blp:~/tmp(0)$ trap - SIGPIPE
> b...@blp:~/tmp(0)$ grep ^Sig /proc/$$/status
> SigQ: 1/16382
> SigPnd:
> Sig
Is the 'printf' command portable enough to be used in configure files
and autoconf macros?
The GNU Coding Standards [1] don't mention it as a portable utility. Indeed,
when you use bash version 1 (which does not have 'printf' built-in) on a
platform that does not have a /usr/bin/printf program, yo
Hi.
Just a tiny patch to make build-aux/vc-list-files to work properly
with GNU Bazaar.
2010-02-21 Jose E. Marchesi
* build-aux/vc-list-files: Invoke bazaar to generate a recursive
list of versioned files based on 'dir' (usage of -R in 'bzr ls').
diff --git a/build-aux/vc-li
Hi.
Just another little patch to avoid some of the sc_* rules to freeze if
the filtering of VC_LIST_EXCEPT gives an empty string (for example,
'make sc_error_exit_success' freezes if there are not source files in
${srcdir}/).
I found this problem due to the bazaar issue in vc-list-files.
2010-
Per discussion last week, here's a patch for init.sh.
The main goal is to allow the EXEEXT shim business to work
also for program names like test-program, (containing a hyphen).
I would have liked to skip the invocation of $re_shell_ -c ...
if the current shell is deemed adequate, but determining
Jim Meyering wrote:
> Per discussion last week, here's a patch for init.sh.
> The main goal is to allow the EXEEXT shim business to work
> also for program names like test-program, (containing a hyphen).
>
> I would have liked to skip the invocation of $re_shell_ -c ...
> if the current shell is de
Jim Meyering wrote:
> Jim Meyering wrote:
>> Per discussion last week, here's a patch for init.sh.
>> The main goal is to allow the EXEEXT shim business to work
>> also for program names like test-program, (containing a hyphen).
>>
>> I would have liked to skip the invocation of $re_shell_ -c ...
On Sun, 21 Feb 2010, Bruno Haible wrote:
Is someone aware of a platform that does not have a /usr/bin/printf or
/bin/printf program?
I am not able to find any. However, the behavior of printf surely
changes over time as standards move forward.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.
jema...@gnu.org wrote:
> Just a tiny patch to make build-aux/vc-list-files to work properly
> with GNU Bazaar.
>
> 2010-02-21 Jose E. Marchesi
>
> * build-aux/vc-list-files: Invoke bazaar to generate a recursive
> list of versioned files based on 'dir' (usage of -R in 'bzr ls').
Tha
Unfortunately, the POT file is very out of date
(http://translationproject.org/POT-files/gnulib-1.0.0.1991.dbebf.pot
Gnulib folks -- perhaps we should set up a cron job to update it
monthly, or some such?
Unfortunately I don't know how the previous pot was generated. Maybe
a Makefile cou
On Sun, 21 Feb 2010, Thomas Dickey wrote:
I am not able to find any. However, the behavior of printf surely changes
over time as standards move forward.
SunOS didn't have one (I don't see it in the manpages, at any rate).
I did check SunOS 5.6 (Solaris 2.6) and it does have one. SunOS 4
pr
Karl Berry ha escrit:
> Gnulib folks -- perhaps we should set up a cron job to update it
> monthly, or some such?
Nice idea. In the meantime I will submit the new potfile tomorrow.
> Unfortunately I don't know how the previous pot was generated. Maybe
> a Makefile could be supplied with a "pot
Bruno Haible writes:
> The GNU Coding Standards [1] don't mention it as a portable utility. Indeed,
> when you use bash version 1 (which does not have 'printf' built-in) on a
> platform that does not have a /usr/bin/printf program, you would be hosed.
> But which platforms are this? The Autoconf
Hello,
I can't help myself, but I am not satisfied with the current choice of
methods how to install a gnulib module (with respect to version control
systmes)?
AFAIK from the manual, there are two possible ways:
- Either one commits everyhing to the repository (I don't like that
since it i
Hi,
Matěj Týč wrote:
> What I don't like about the second solution is the necessity of having
> gnulib-tool available. ...
> ... should be performed manually from the gnulib git.
> You surely can imagine that the difficulty of the build process would
> increase because of this.
Well, "manually" d
Hi Jim,
> I tested init.sh on Solaris 10 by doing this locally,
>
> ./gnulib-tool --create-testdir --with-tests --dir=tt xstrtoll
>
> Running (in tt) ./configure && make && make dist, and copying the tarball
> to the Solaris system.
You don't need to "./configure && make && make dist" in a gn
16 matches
Mail list logo
