Alfred M. Szmidt wrote:
> They are only non-portable across different operating systems (say
> OpenBSD vs GNU). My point is that coreutils main goal is not to be
> portable across various operating systems, if `uname -p' outputs
> `unknown' on platforms that can't provide that info, then that is
>
Egmont Koblinger <[EMAIL PROTECTED]> writes:
> I guess tr should support multibyte character sets, even if not by default,
> then by providing a command line option.
That'd be nice. It's a bit tricky, though. Doing it right would
require that tr support encoding errors (stray byte sequences tha
>I don't think it will break scripts because legacy operating
>systems don't support those options either.
^^
> If you consider GNU a legacy operating system, sure. Recall, GNU
> coreutils is for GNU, not non-GNU systems.
Not
Alfred M. Szmidt wrote:
>I don't think it will break scripts because legacy operating
>systems don't support those options either.
^^
> If you consider GNU a legacy operating system, sure. Recall, GNU
> coreutils is for GNU, not non-GNU system
> > I have often thought it would be better if on machines that
> > could not reasonably support those extra uname options that
> > the options be disabled entirely. Then instead of unknown the
> > program would report it as an invalid option.
>
> But that will break scripts
Since POSIX doesn't document -p or -i, they are already non-portable
options.
GNU Coreutils isn't POSIX Coreutils.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Alfred M. Szmidt wrote:
> > I have often thought it would be better if on machines that could
> > not reasonably support those extra uname options that the options
> > be disabled entirely. Then instead of unknown the program would
> > report it as an invalid option.
>
> But that will break s
Hi,
tr (from coreutils 5.2.1, but I saw no changelog entry corresponding to this
in 5.3.0) doesn't support UTF-8 encoding. This is an excerpt from a terminal
set to UTF-8 mode and LANG=hu_HU.UTF-8 (no LC_* variable);
$ echo á | tr á a
aa
$ echo a | tr a á
$
I guess tr should support multibyte
>> That's been discussed, but it sounds like a can of worms.
>
>I have often thought it would be better if on machines that could
>not reasonably support those extra uname options that the options
>be disabled entirely. Then instead of unknown the program would
>report it as a
Jim Meyering <[EMAIL PROTECTED]> wrote:
...
> 2005-09-14 Jim Meyering <[EMAIL PROTECTED]>
>
> * strftime.c (my_strftime): Parse the colons of %:::z *after* the
> optional field width, not before, so we accept %9:z, not %:9z.
>
> 2005-09-14 Jim Meyering <[EMAIL PROTECTED]>
>
>
> That's been discussed, but it sounds like a can of worms.
I have often thought it would be better if on machines that could
not reasonably support those extra uname options that the options
be disabled entirely. Then instead of unknown the program would
report it as an invalid op
Paul Eggert wrote:
> That's been discussed, but it sounds like a can of worms.
I have often thought it would be better if on machines that could not
reasonably support those extra uname options that the options be
disabled entirely. Then instead of unknown the program would report
it as an invali
Hi,
This is an initial rough draft of a patch to add exec and pause support to
the split command.
The basic idea is to let the user have some control of what happens to
each output file as it is created. A command may be run (say burning
file chunks to CD), or split can pause for the user to pre
Paul Eggert <[EMAIL PROTECTED]> wrote:
> 2005-09-13 Paul Eggert <[EMAIL PROTECTED]>
>
> * NEWS: date has a new --rfc-3339 option, and the old --iso-8601
> option is deprecated. date and ls also have new time format
> specifiers %:z, %::z, %:::z.
So my threat of incoming fprint
Eric Blake <[EMAIL PROTECTED]> writes:
> What about parsing /proc/cpuinfo, on machines that have that?
That's been discussed, but it sounds like a can of worms. The
information doesn't map all that well to the uname output, and my
admittedly uninformed feeling is that it is not that standard amo
Eric Blake <[EMAIL PROTECTED]> writes:
> All I could think of when the problem first came up was %Ez, since %E
> specifies alternate format, but that doesn't really fit the three formats
> you provided, so your choice seems great to me.
Thanks. Also, %E is supposed to be about locales, but this
16 matches
Mail list logo
