* Paul Eggert wrote on Tue, Apr 10, 2007 at 06:45:35PM CEST:
> [EMAIL PROTECTED] (Karl Berry) writes:
>
> >> POSIX prohibits the use of NUL in Awk input
> >> files, so portable scripts can't assume it.
> >
> > Sure, but in the particular case of bootstrapping gnu packages, if gawk
> > works, that
[EMAIL PROTECTED] (Karl Berry) writes:
>> POSIX prohibits the use of NUL in Awk input
>> files, so portable scripts can't assume it.
>
> Sure, but in the particular case of bootstrapping gnu packages, if gawk
> works, that seems pretty sufficient to me?
Ah, sorry, I didn't realize the context was
> POSIX prohibits the use of NUL in Awk input
> files, so portable scripts can't assume it.
Sure, but in the particular case of bootstrapping gnu packages, if gawk
works, that seems pretty sufficient to me? I don't see why we need to
cater for other implementations in *GNU* libtool. It's not lik
[EMAIL PROTECTED] (Karl Berry) writes:
> what is the issue with awk and NUL bytes? Does gawk really
> eat NULs? Or is it other awks that are the problem? Or is the problem
> theoretical?
Old versions of Gawk mishandle NUL in some cases, though I don't know
of any bugs in the latest stable vers
[EMAIL PROTECTED] (Karl Berry) writes:
> Is there any modern (or even not-so-modern) system that does not provide
> fold and cut?
It's not just a question of whether it provides fold and cut. It's a
question of whether it provides versions that are reliable enough for
our purposes (which include
two lists of tools: one in [EMAIL PROTECTED] Utilities in Makefiles' and
one in
[EMAIL PROTECTED] Install Command Categories'. Should libtool now need to
restrict itself to the intersection of both lists, as it is invoked
both at build and install time
I believe "intersection" is
As an extreme example, we can't assume 'shuf' (recently added to
coreutils).
Of course.
'fold' and 'cut' are not nearly as extreme as that, but
they do tend to be less-used in portable software.
Is there any modern (or even not-so-modern) system that does not provide
fold and c
[EMAIL PROTECTED] (Karl Berry) writes:
> Personally, since we're already listing some of the programs from
> coreutils, I don't really see a lot of practical issues arising from
> adding any others. Or am I missing something?
We can't assume that coreutils is installed. Lots of people build
wit
So I gather that `fold', `cut', and `paste' stand no chance of
ending up listed in make-stds.texi?
I've never approached rms about adding to the command lists, but it
seems reasonable to suppose that he would want a justification for each
one, ie, why the job can't be reasonably accomplish
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> So I gather that `fold', `cut', and `paste' stand no chance of ending up
> listed in make-stds.texi?
I'm not the one making that decision, but I suspect the probability is
low, yes, unless there's a stronger case than I've heard so far.
> I sense a m
Ralf Wildenhues asked:
> So, how portable are these tools?
If you are interested in a reliable answer soon, you can write tests for
these tools that check the command line options and behaviours that you
are interested in. Commit them to gnulib, and we'll do the portability
testing for you.
For r
* Paul Eggert wrote on Thu, Apr 05, 2007 at 06:19:16PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > fold, split, join, cut, paste
>
> 'split' and 'join' are traditional and portable. 'fold', 'cut', and
> 'paste' are relative newcomers, as they were not part of Unix Version 7
> and
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> join perhaps; it's quite stable so long as you run it in the C locale
>> and stick to the old features. cut I'm not so sure about; it's kind
>> of persnickety.
>
> What exactly does the word "persnickety" mean here, and in which way is
> cut that way
13 matches
Mail list logo
