On 03 Nov 2015 18:25, Chet Ramey wrote:
> On 11/3/15 4:45 PM, Greg Wooledge wrote:
> > To the surprise of approximately zero people, loadable builtins don't
> > fully work on HP-UX.
> >
> > I'll spare you any results from 10.20 because it's totally unsupported
> > at this point. (It doesn't even
The shell-expand-line command (bound to Escape-Ctrl-E) incorrectly removes
quotation marks from
the command line, often resulting in a command that differs from what the
user intended to type.
I've seem this problem with all recent versions of bash, particularly
4.3.11 (preinstalled on
Linux Mint
On 11/3/15 4:45 PM, Greg Wooledge wrote:
> To the surprise of approximately zero people, loadable builtins don't
> fully work on HP-UX.
>
> I'll spare you any results from 10.20 because it's totally unsupported
> at this point. (It doesn't even use dlopen().)
>
> On HP-UX 11.11, things half work
Eric Blake writes:
> There is NO way for any program using getopt() or getopt_long() to know
s/using getopt() or getopt_long()//
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely differe
To the surprise of approximately zero people, loadable builtins don't
fully work on HP-UX.
I'll spare you any results from 10.20 because it's totally unsupported
at this point. (It doesn't even use dlopen().)
On HP-UX 11.11, things half work. This is with 4.4-beta, sitting in the
.../examples/l
[adding the list back in, with permission]
On 11/03/2015 11:43 AM, Julio C. Neves wrote:
> I'm sorry to disturb you.
I have no problem replying to messages, so no need to apologize for
disturbing me. My only problem is when messages are sent to just me
instead of the public list, because then it
[adding the list back in with permission; please don't send private
mails when the discussion may benefit others]
[please don't top-post on technical lists]
On 11/03/2015 11:03 AM, Julio C. Neves wrote:
> Hi Eric, I wrote NUL because my english is not the best of the world, I
> wanna mean "empty"
On 11/03/2015 01:09 PM, Dennis Williamson wrote:
> On Nov 3, 2015 12:47 PM, "Julio C. Neves" wrote:
>>
>> Thanks Dennis,
>> I know that you are rigth, but "paste -d"" odd even" and "paste -d "" odd
> even" are not the same? The diference is only a space between the option
> and its parameter.
The
On Nov 3, 2015 12:47 PM, "Julio C. Neves" wrote:
>
> Thanks Dennis,
> I know that you are rigth, but "paste -d"" odd even" and "paste -d "" odd
even" are not the same? The diference is only a space between the option
and its parameter.
>
> Abcs,
> Julio
> @juliobash
>
> Próximos cursos de Shell
>
On 11/3/15 9:03 AM, Corentin Peuvrel wrote:
> Hi,
>
> I think I found a bug in bash-4.3 (4.3.42 in fedora 21), that seems to exists
> for a long time (at least from 4.1.2 in Centos 6).
>
> I found a fairly simple way to reproduce it : you have to initialize a
> variable to an empty string, and
julio.ne...@gmail.com writes:
> $ paste -d"" odd even
This is the same as `paste -d odd even', so the delimiter list is odd.
As there is only one file, this in turn is the same as `paste even'.
Ultimately this is the same as `cat even'.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Tue, Nov 3, 2015 at 10:29 AM, wrote:
> An example is better than thousand words:
>
> $ seq 1 2 9 > odd
> $ seq 2 2 10 > even
> $ paste -d "" odd even
> 12
> 34
> 56
> 78
> 910
> $ paste -d"" odd even
> 2
> 4
> 6
> 8
> 10
>
> Like you can see, with no space between the option (-d) and the null
On 11/03/2015 09:29 AM, julio.ne...@gmail.com wrote:
> An example is better than thousand words:
>
> $ seq 1 2 9 > odd
> $ seq 2 2 10 > even
> $ paste -d "" odd even
> 12
> 34
> 56
> 78
> 910
> $ paste -d"" odd even
This is equivalent to:
paste -dodd even
which is NOT the same as the NUL delimi
An example is better than thousand words:
$ seq 1 2 9 > odd
$ seq 2 2 10 > even
$ paste -d "" odd even
12
34
56
78
910
$ paste -d"" odd even
2
4
6
8
10
Like you can see, with no space between the option (-d) and the null parameter
(""), we have an unexpected result
On 11/2/15 7:36 PM, Dennis Williamson wrote:
> I guess the point I'm trying to get to is that I don't see
> how "${colors[*]@a}" or "${colors@A}" are useful whereas their opposites
> are ("${colors@a}" and "${colors[*]@A}") regardless of whether the
> parameter is an array or scalar. By the way, s
Hi,
I think I found a bug in bash-4.3 (4.3.42 in fedora 21), that seems to exists
for a long time (at least from 4.1.2 in Centos 6).
I found a fairly simple way to reproduce it : you have to initialize a variable
to an empty string, and do a comparaison to it while doing the case
modification
16 matches
Mail list logo
