Date:Tue, 16 Mar 2021 22:08:17 -0500
From:Dennis Williamson
Message-ID:
| In any case this points to larger chunks being more efficient.
This is not news, doing reads (or writes) using bigger buffers (more
bytes at a time) means less system calls, and compared to
Date:Tue, 16 Mar 2021 18:01:24 -0400
From:Jay via Bug reports for the GNU Bourne Again SHell
Message-ID: <86f1f224-2930-ee73-5431-6e130d92f...@aim.com>
First, thanks Lawrence for the translation from RTF, I am one of
the people he intended to help... The RTF form I
Date:Tue, 16 Mar 2021 13:26:30 +0100
From:Alex fxmbsw7 Ratchev
Message-ID:
| no idea about your internal rules of keyword and builtin but clearly its
| gotta parse it at most 1. level otherwise its big security fault isnt it
No, it isn't. No more than
.
On Tue, Mar 16, 2021, 10:22 PM Lawrence Velázquez wrote:
> > On Mar 16, 2021, at 11:08 PM, Dennis Williamson <
> dennistwilliam...@gmail.com> wrote:
> >
> > I've been playing with your optimized code changing the read to grab data
> > in chunks like some of the other optimized code does - thus
> On Mar 16, 2021, at 11:08 PM, Dennis Williamson
> wrote:
>
> I've been playing with your optimized code changing the read to grab data
> in chunks like some of the other optimized code does - thus extending your
> move from by-word to by-line reading to reading a specified larger number
> of c
Date:Tue, 16 Mar 2021 09:31:24 -0400
From:Chet Ramey
Message-ID: <31aff163-9e61-d34a-be79-40c7e09a8...@case.edu>
| If you want to set PWD instead of letting cd/pushd/popd manage it,
| all bets are off.
I agree with that as far as what you get when you expand $PWD
On Tue, Mar 16, 2021, 6:19 PM Lawrence Velázquez wrote:
> > On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne
> Again SHell wrote:
> >
> > Hello,
> >
> > I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
> > systems more than once either through their
> On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne Again
> SHell wrote:
>
> Hello,
>
> I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
> systems more than once either through their instability with libraries
> or just excess stress.
>
> I don'
Hello,
I have been using/exploring Linux for ~ 2yrs; have corrupted a couple
systems more than once either through their instability with libraries
or just excess stress.
I don't consider current case to be either of the above; see attached.
The system is modern Intel computer,
On 3/16/21 11:38 AM, Mike Jonkmans wrote:
A 'make distclean' removes lib/readline/doc/Makefile
It is a handmade Makefile, so probably should not be removed.
Thanks for the report. It shouldn't be in the bash distribution at all; it
exists only for my convenience.
--
``The lyf so short, the cr
On 16/03/2021 16:21, Chet Ramey wrote:
On 3/16/21 11:07 AM, Michael Felt wrote:
On 16/03/2021 14:38, Chet Ramey wrote:
On 3/16/21 8:04 AM, Michael Felt wrote:
Decided to give bash-5.1 a try. I doubt it is major, but I get as
far as:
"../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11:
A 'make distclean' removes lib/readline/doc/Makefile
It is a handmade Makefile, so probably should not be removed.
Idem for maintainer-clean.
Regards, Mike Jonkmans
diff --git lib/readline/doc/Makefile lib/readline/doc/Makefile
index af5ee3e5..6bc2e5ea 100644
--- lib/readline/doc/Makefile
+++ l
On 3/16/21 11:07 AM, Michael Felt wrote:
On 16/03/2021 14:38, Chet Ramey wrote:
On 3/16/21 8:04 AM, Michael Felt wrote:
Decided to give bash-5.1 a try. I doubt it is major, but I get as far as:
"../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W)
Operation between types "ch
On 16/03/2021 14:38, Chet Ramey wrote:
On 3/16/21 8:04 AM, Michael Felt wrote:
Decided to give bash-5.1 a try. I doubt it is major, but I get as far
as:
"../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W)
Operation between types "char*" and "int" is not allowed.
ld: 0711-
On 3/16/21 8:04 AM, Michael Felt wrote:
Decided to give bash-5.1 a try. I doubt it is major, but I get as far as:
"../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W)
Operation between types "char*" and "int" is not allowed.
ld: 0711-317 ERROR: Undefined symbol: .mkdtemp
Th
okay, cool, thank you for valuable infos =))
On Tue, Mar 16, 2021 at 2:31 PM Chet Ramey wrote:
> On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote:
> > .. ?
> >
> > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
> > 2021-03-16+11:22:2920 ) #
> > PWD=/bla
>
> No. If you want to s
On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote:
.. ?
# root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
2021-03-16+11:22:2920 ) #
PWD=/bla
No. If you want to set PWD instead of letting cd/pushd/popd manage it,
all bets are off.
Just like setting HOME changes tilde expansion.
as for shell keyword be more important and vital to shells, than more
external [or so?] built ins
unset -v var ## very internal to shell var extension thatss not possible to
disable
[[ .. ## a test for strings or so containing
..
it would not make sense to have unset be lower than [[
On Tue, Mar
i guess shell-keyword all then :))
On Tue, Mar 16, 2021 at 1:37 PM Greg Wooledge wrote:
> On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote:
> > no idea about your internal rules of keyword and builtin
>
> unicorn:~$ type [
> [ is a shell builtin
> unicorn:~$ type [[
> [[ is a
On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote:
> no idea about your internal rules of keyword and builtin
unicorn:~$ type [
[ is a shell builtin
unicorn:~$ type [[
[[ is a shell keyword
You know how you're allowed to omit quotes inside [[ but not inside [ ?
That's because [
but is it a bug
its a bug to use heavy subshells for such
i understand the addment of this case tho
On Tue, Mar 16, 2021 at 1:23 PM Chris Elvidge wrote:
> On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote:
> > .. ?
> >
> > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
> > 2
no idea about your internal rules of keyword and builtin but clearly its
gotta parse it at most 1. level otherwise its big security fault isnt it
its a shell fuctionality keyword, unset, so ..
On Tue, Mar 16, 2021 at 1:21 PM Greg Wooledge wrote:
> On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex f
On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote:
.. ?
# root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
2021-03-16+11:22:2920 ) #
PWD=/bla
# root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 ==
2021-03-16+11:23:1920 ) #
Yes, it seems \w (and \W) take their values from
On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex fxmbsw7 Ratchev wrote:
> it doesnt make me much sense that unset -v assoc[$key] gives syntax error
> or so..
Think of it this way: what would happen if you had a filename in a
variable -- say, $file -- and you ran this command:
rm -f $file
You'd exp
On 11/03/2021 22:27, Chet Ramey wrote:
On 3/11/21 3:55 PM, Michael Felt (aixtools) wrote:
Sent from my iPhone
On 11 Mar 2021, at 18:15, Chet Ramey wrote:
On 3/11/21 11:28 AM, Michael Felt wrote:
Hi,
Issue: AdoptOpenJDK build process makes bash calls in a particular
way. An abbreviated
.. ?
# root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 ==
2021-03-16+11:22:2920 ) #
PWD=/bla
# root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 ==
2021-03-16+11:23:1920 ) #
hello, excuse my bad english
your sample code that you write what it should produce you propose for the
future so ?
it doesnt make me much sense that unset -v assoc[$key] gives syntax error
or so..
also about the assoc_expand_once i dont understand
cant it be as written, expand_once ( maybe _at_b
27 matches
Mail list logo
