Sorry I couldn't use bugbash - I don't work with source.
I've attached a complete description of the bug.
Regards,
Rob Robason
Driving Breakthrough Performance in Software Product Quality and
Development Practices
Phone:
925-825-1512
Home:
Concord, CA 94518
Mo
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-unknown-linux-gnu' -
DCONF_VENDOR='unknown' -DLOCALEDIR='/home/trnka/opt/
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash
On Thu, Mar 25, 2010 at 03:32:25AM -0700, Rob Robason wrote:
> The printf builtin is broken in many variations of use of '*' (e.g., "%.*s")
> in a printf conversion spec to set field width and precision from argument
> values.
The use of '*' as a field width is not required by POSIX. According
> Bash Version: 4.0
> Patch Level: 33
> Release Status: release
>
> Description:
> suppose there is a dir called "1" when i'm in it and i use "mv ../1
> ../44" command for example, mv does the job. but nor pwd or shell prompt
> does not show the change until i go back to the parent of "1" dire
On 3/25/10 6:32 AM, Rob Robason wrote:
> Sorry I couldn't use bugbash - I don't work with source.
>
> I've attached a complete description of the bug.
Thanks for the report. It's a simple bug, with a simple fix. I've
attached a patch, but it may not be useful to non-source users.
Chet
--
``Th
[please keep the list in the loop]
On 03/25/2010 12:20 AM, Siddhesh Poyarekar wrote:
> On Tue, Mar 23, 2010 at 9:30 PM, Siddhesh Poyarekar
> wrote:
>>> I see no bug - bash is within its rights to pretend that an inherited
>>> ignored SIGINT has no trap setting, seeing as how the user cannot modif
On Thu, Mar 25, 2010 at 7:19 PM, Eric Blake wrote:
> Technically, this is only a POSIX requirement on non-interactive shells.
> Interactive shells may reset ignored signals on entry, effectively
> starting life as if nothing had been inherited ignored. But I don't
> know (without looking at the
On 03/25/2010 08:39 AM, Siddhesh Poyarekar wrote:
> On Thu, Mar 25, 2010 at 7:19 PM, Eric Blake wrote:
>> Technically, this is only a POSIX requirement on non-interactive shells.
>> Interactive shells may reset ignored signals on entry, effectively
>> starting life as if nothing had been inherite
On Thu, Mar 25, 2010 at 8:13 PM, Eric Blake wrote:
> Subshells are different than new shells on what POSIX requires for
> signal manipulations. Again, quoting POSIX:
>
> "When a subshell is entered, traps that are not being ignored are set to
> the default actions. This does not imply that the tr
On 03/25/2010 01:32 PM, Siddhesh Poyarekar wrote:
> In a terminal, execute a script which does basically this:
>
> trap '' SIGTERM
> ...
> bash
>
> According to the above explanation, the resultant bash prompt I get on
> execution of this script will allow me to override the ignored SIGTERM
> sin
On Fri, Mar 26, 2010 at 2:40 AM, Eric Blake wrote:
> Yes. POSIX requires this for non-interactive shells, and does not
> forbid it for interactive shells. Technically, this code could be
> modified to exempt interactive shells from hard-ignores, or left as is
> by treating both classes of shells
On Fri, Mar 26, 2010 at 11:20 AM, Siddhesh Poyarekar
wrote:
> The code does explicitly hard ignore signals ignored when entering a
> non-interactive shell; see initialize_terminating_signals() in sig.c.
> The problem is that in addition to this, it ends up doing a hard
> ignore for the special sig
13 matches
Mail list logo
