On Mon, 25 Apr 2022, 22:03 Chet Ramey, wrote:
> On 4/22/22 9:51 AM, Sam Liddicott wrote:
>
> > Please could we at least have a shopt to maintain the old
> behaviour?
>
> Let's start with making it part of BASH_COMPAT=50.
>
Thanks- that's great.
Sa
Thanks for that important context.
Chet Ramey once said:
> One can argue that the concerns on either side (seeking on stdin vs.
> assuming that here-strings will never hit the file system) are assumptions
> that should not be made,
In reality no-one is making such an assumption, neither idea ente
e("/dev/fd/3"))'
3<< /dev/pts/1
lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:05 1 -> /dev/pts/1
lrwx-- 1 sliddicott sliddicott 64 Apr 22 16:05 2 -> /dev/pts/1
lr-x-- 1 sliddicott sliddicott 64 Apr 22 16:05 3 ->
'/tmp/tmp.rkDXYvp4hn (deleted)'
lr-x---
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
-Wall
uname output: Linux junior 5.15.0-25-g
On Sun, 19 Apr 2020 at 20:40, Chet Ramey wrote:
>
> On 4/17/20 6:37 PM, Robert Elz wrote:
>
> > This happens only because of the cheap way we (and I presume you)
> > implement things - in any rational scheme, it would take the precision
> > chars from the source string, and then quote them.
That,
In my case I was using process substitution to generate a dynamic bashrc
file as part of invoking an SDK environment.
Naturally those lines which emit environment variable assignments use %q
I had one build version tracking variable which was to be limited to 7
characters and set to a lowercase f
So is it to be "fixed" in the documentation with a warning that
truncating-size specifiers for %q may nullify the safety benefits for which
it is used?
Sam
On Fri, 17 Apr 2020, 21:12 Chet Ramey, wrote:
> On 4/17/20 10:22 AM, Sam Liddicott wrote:
>
> > Bash Version: 4
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
add it to the wishlist for bash 5 ;-)
On Thu, 25 Jul 2019 at 15:11, Chet Ramey wrote:
> On 7/25/19 9:03 AM, Sam Liddicott wrote:
>
> > Perhaps if the named fd is also closed on the same statement that opened
> > it, it could be kept closed rather than saved and re-opened.
&g
to close the fd
I appreciate your time and the maintenance of bash and readline.
thanks again
Sam
On Thu, 25 Jul 2019 at 12:52, Chet Ramey wrote:
> On 7/24/19 9:07 AM, Sam Liddicott wrote:
> > Thanks for that thoughtful response.
> >
> > * I understand that the desi
ternal (long lived) commands
This would allow users to have full and safe benefit of bash-selected fd's,
which I am sure is what is intended.
I have done my best to be clear in a reasonable manner, but you are the
man, it is your project, we stand or fall by your decisions, not mine.
Sam
O
and 2 or between 2 and 4.
Sam
On Tue, 23 Jul 2019, 21:57 Chet Ramey, wrote:
> On 7/23/19 12:12 PM, Sam Liddicott wrote:
>
> > Given what you have explained as intentional, it the difference between 1
> > and 2, but it is best understood as a 4-way difference, outlined here:
&g
On Tue, 23 Jul 2019 at 16:45, Chet Ramey wrote:
> On 7/23/19 11:40 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:35, Chet Ramey > <mailto:chet.ra...@case.edu>> wrote:
> >
> > On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >
On Tue, 23 Jul 2019 at 16:35, Chet Ramey wrote:
> On 7/23/19 11:20 AM, Sam Liddicott wrote:
> >
> > On Tue, 23 Jul 2019 at 16:15, Sam Liddicott > <mailto:s...@liddicott.com>> wrote:
> >
> >
> >
> > On Tue, 23 Jul 2019 at 16:13, Ch
On Tue, 23 Jul 2019 at 16:15, Sam Liddicott wrote:
>
>
> On Tue, 23 Jul 2019 at 16:13, Chet Ramey wrote:
>
>> On 7/23/19 11:11 AM, Sam Liddicott wrote:
>>
>> > The report concerns the different behaviour with internal and external
>> > operations.
&g
On Tue, 23 Jul 2019 at 16:13, Chet Ramey wrote:
> On 7/23/19 11:11 AM, Sam Liddicott wrote:
>
> > The report concerns the different behaviour with internal and external
> > operations.
>
> Right. The close-on-exec is deliberate. That's how it was intended.
>
Doe
On Tue, 23 Jul 2019 at 16:05, Chet Ramey wrote:
> On 7/23/19 10:33 AM, Sam Liddicott wrote:
>
> > Bash Version: 4.4
> > Patch Level: 20
> > Release Status: release
> >
> > Description:
> > Bash redirection sequence cases a file descriptor to be lea
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
On Tue, Nov 27, 2012 at 7:08 AM, Pierre Gaston wrote:
>
>
> On Mon, Nov 26, 2012 at 10:48 PM, Chet Ramey wrote:
>
>> On 11/26/12 12:11 PM, Sam Liddicott wrote:
>> > 3. there already exists simple and explicit way to get the supposed
>> benefit
>> > usi
On Mon, Nov 26, 2012 at 5:02 PM, Chet Ramey wrote:
> On 11/26/12 9:26 AM, Sam Liddicott wrote:
>
> > It seems that ksh93 behaves just like bash in this regard
> > Well, as I don't use it I don't really care, but I vote for this as a
> > bug as
On Mon, Nov 26, 2012 at 1:49 PM, Pierre Gaston wrote:
>
>
> On Mon, Nov 26, 2012 at 3:41 PM, Pierre Gaston wrote:
>
>>
>>
>> On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey wrote:
>>
>>> On 11/23/12 2:04 AM, Pierre Gaston wrote:
>>>
>>> > It seems rather counter intuitive that the fd is not closed af
On Thu, Nov 22, 2012 at 7:15 PM, Chet Ramey wrote:
> On 11/16/12 10:47 AM, Sam Liddicott wrote:
> > Repeated executions of: { echo $fd ; } {fd}> /dev/null
> > will emit different numbers, indicating that fd is not closed when the
> > block completes.
>
> This is int
Repeated executions of: { echo $fd ; } {fd}> /dev/null
will emit different numbers, indicating that fd is not closed when the
block completes.
As an interesting aside it seems not to be possible to close the FD within
the block either:
{ echo $fd ; eval exec "$fd>&-" ; } {fd}> /dev/null
On 23/03/11 20:32, Maarten Billemont wrote:
On 23 Mar 2011, at 21:28, Chet Ramey wrote:
OK. What wording would you like to see?
I don't mind the wording he proposed:
On 23 Mar 2011, at 17:12, Sam Liddicott wrote:
maybe it should say
BASH_SUB
On 23/03/11 18:52, Chris F.A. Johnson wrote:
On Wed, 23 Mar 2011, Sam Liddicott wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCO
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DP$ uname
27 matches
Mail list logo
