Date:Fri, 14 Jun 2024 13:34:28 +1200
From:Martin D Kealey
Message-ID:
| To be clear, this isn't a bug report, but rather a feature request to
| implement a common extension, and to interpret TZ=...,M*m.w* printf in line
| with the rest of GNU.
To that you'd w
On Thu, 13 Jun 2024 at 09:05, Zachary Santer wrote:
>
> Let's say, if var is in the form of a C floating-point literal,
> ${var@F} would expand it to the locale-dependent formatted number, for
> use as an argument to printf or for output directly. And then ${var@f}
> would go the other way, takin
On Fri, 14 Jun 2024 at 10:52, Robert Elz wrote:
> | I also note a minor bug/issue with printf in Bash 5.3-alpha: the
> builtin
> | printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC.
>
> That's user error, POSIX format requires 3 values after the M:
"User error" is not th
On Fri, 14 Jun 2024 at 06:13, Dan Jacobson wrote:
> ./k
> make: ./k: No such file or directory
>
This is a problem with the POSIX spec for the execve system call and its
obligatory return codes.
"No such file or directory" is arguably the correct message to show when
the kernel returns the ENOE
Date:Fri, 14 Jun 2024 00:31:31 +1200
From:Martin D Kealey
Message-ID:
| I also note a minor bug/issue with printf in Bash 5.3-alpha: the builtin
| printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC.
That's user error, POSIX format requires 3
Date:Thu, 13 Jun 2024 11:51:13 -0400
From:"Dale R. Worley"
Message-ID: <87jzisx2mm@hobgoblin.ariadne.com>
| For instance, how should this be logged?
|
| $ { echo foo ; echo bar ; } >/dev/null
In the NetBSD shell:
[jacaranda]{2}$ { echo foo ; echo bar
On Fri, Jun 14, 2024 at 02:13:37AM +0800, Dan Jacobson wrote:
> $ echo \#!/usr/bin/python > k
> $ chmod +x k
> $ ./k
> bash: ./k: cannot execute: required file not found
>
> Bash should really mention what file it is talking about.
Bash doesn't KNOW what file is missing. All it knows is that the
On Thu, Jun 13, 2024 at 06:12:21PM +0200, Andreas Schwab wrote:
> Why do you think this is a bug in bash? You are telling the shell to
> export any modified variable, and you get what you asked for.
I started writing something like this as well but deleted it. I think
there's still a bit of subt
$ echo \#!/usr/bin/python > k
$ chmod +x k
$ ./k
bash: ./k: cannot execute: required file not found
Bash should really mention what file it is talking about.
$ echo 'x:k; ./$<' > Makefile
$ make
./k
make: ./k: No such file or directory
make: *** [Makefile:1: x] Error 127
$ ls ./k
./k
Make is wor
On 6/5/24 12:32 PM, Thomas Deutschmann wrote:
Hello!
I would like to report an issue with bash version >=5.2.
For years, I have had the following line in my ~/.bashrc:
export HISTTIMEFORMAT="[$(tput setaf 6)%F %T$(tput sgr0)]: " # colorful date
This worked perfectly up to and including bash
On Thursday, June 13, 2024, Chet Ramey wrote:
>
> The value of COLUMNS gets modified, and auto-exported since you have
> `set -a' enabled.
>
Okay, so the documentation adds up. Doesn't mean it's not a bug.
If you were a normal user and were faced with the behavior presented in OP,
wouldn't you t
Date:Wed, 12 Jun 2024 19:31:13 +0200
From:Angelo Borsotti
Message-ID:
| I would stress the importance of this: the purpose of scripts is
| to execute commands,
Yes.
| informing the caller of what they execute,
No. If a script wants to provide output like
Date:Thu, 13 Jun 2024 14:41:24 +
From:Alain BROSSARD via Bug reports for the GNU Bourne Again SHell
Message-ID:
| 1. Bash with -a , under some conditions, exports to the environment
| the variable COLUMNS which it shouldn’t
That one is debatable
On 6/13/24 1:45 PM, Alain BROSSARD via Bug reports for the GNU Bourne Again
SHell wrote:
Hi Andreas,
Sure, the variables explicitly assigned to get exported, that is the
expected behavior.
But there is nothing which explains why the variable COLUMNS becomes an
environment variable.
OK.
On Thu, Jun 13, 2024 at 06:28:23PM +, Alain BROSSARD via Bug reports for
the GNU Bourne Again SHell wrote:
>My conclusion is that the variable COLUMNS gets “reset” when there is a
> pipe in a command and further gets EXPORTED if “set -a” was set before hand :
>
> host:/$ COLUMNS=80
> hos
Hi,
You are correct, export COLUMNS does truncate, I had made the mistake of
replaying the previous execution of ps which was with “axww”.
Something does go wrong once COLUMNS is in the environment, it seems that in
that case, it can get modified when executing a pipe’d command.
As the
On 6/13/24 8:31 AM, Martin D Kealey wrote:
On Tue, 11 Jun 2024 at 21:52, Grisha Levit wrote:
POSIX says about the TZ variable:
If the dst field is specified and the rule field is not, it is
implementation-defined when the changes to and from DST occur.
musl seems to interpret `TZ=E
Hi Andreas,
Sure, the variables explicitly assigned to get exported, that is the
expected behavior.
But there is nothing which explains why the variable COLUMNS becomes an
environment variable.
Run “ps ax” twice and the results of the second execution is different from
the first if an
On Thu, Jun 13, 2024 at 11:51:13AM -0400, Dale R. Worley wrote:
> For instance, how should this be logged?
>
> $ { echo foo ; echo bar ; } >/dev/null
> + echo foo
> + echo bar
I'm 99% sure I know what answer the OP of this thread will give:
"It should write '{ echo foo ; echo bar ; }
On 6/11/24 5:52 AM, Grisha Levit wrote:
POSIX says about the TZ variable:
If the dst field is specified and the rule field is not, it is
implementation-defined when the changes to and from DST occur.
musl seems to interpret `TZ=EST5EDT` as having DST always in effect,
causing the test
On Thursday, June 13, 2024, Alain BROSSARD wrote:
>
> export COLUMNS=60
>
> ps ax | grep java
>
>
>
> The output isn’t truncated.
>
> It is on my machine. You must have something in your PS1/PROMPT_COMMAND
interfering.
> It is critical that application’s behaviour do not get impacted by the
>
Why do you think this is a bug in bash? You are telling the shell to
export any modified variable, and you get what you asked for.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi,
It still doesn’t explain why this is happening.
If you simply do :
export COLUMNS=60
ps ax | grep java
The output isn’t truncated. Remember that PS’s output goes through a pipe
so the terminal width shouldn’t matter. Without “-a”, we always get the full
output.
It is critical t
Angelo Borsotti writes:
> the solution to show commands with "set -x" has, however, a flow: it
> does not show properly commands that contain redirections. E.g.,
...
> cat f1.txt f1.txt > f1.tmp
But showing redirections properly is difficult, not just in the
implementation, but in what it *means*
sorry i didnt see full mail .. bb ..
On Thu, Jun 13, 2024, 4:22 PM alex xmb sw ratchev wrote:
> it looks like normal cut ps out
> try .. ps axw
> maybe be some terminal lines 2nd+ hashing error
>
> On Thu, Jun 13, 2024, 3:46 PM Alain BROSSARD wrote:
>
>> Hi,
>>
>>
>>
>> The why doesn’t mat
i actually always did ww , but i didnt know here the difference ..
On Thu, Jun 13, 2024, 4:24 PM Oğuz wrote:
> On Thursday, June 13, 2024, Alain BROSSARD via Bug reports for the GNU
> Bourne Again SHell wrote:
> >
> ># however, the second one has truncated output to the terminal
> width
On Thursday, June 13, 2024, Alain BROSSARD via Bug reports for the GNU
Bourne Again SHell wrote:
>
># however, the second one has truncated output to the terminal width
>
Looks like `set -a' exports COLUMNS for some reason, this must be a bug
$ set -a
$ env | grep COLUMNS
$ env | grep CO
it looks like normal cut ps out
try .. ps axw
maybe be some terminal lines 2nd+ hashing error
On Thu, Jun 13, 2024, 3:46 PM Alain BROSSARD wrote:
> Hi,
>
>
>
> The why doesn’t matter, but it is a third party software package.
> They source different files from different location which defin
Hi,
The why doesn’t matter, but it is a third party software package. They
source different files from different location which define variables. They set
-a before and +a after. I’m stuck in the middle. As long as I didn’t trigger
the bug, it didn’t matter.
Changing the parameters of
try the ps arg w for full length ps output
why u set -a ?
On Thu, Jun 13, 2024, 3:29 PM Alain BROSSARD via Bug reports for the GNU
Bourne Again SHell wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLA
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 admu01-rgr-gva 5
On Tue, 11 Jun 2024 at 21:52, Grisha Levit wrote:
> POSIX says about the TZ variable:
>
> If the dst field is specified and the rule field is not, it is
> implementation-defined when the changes to and from DST occur.
>
> musl seems to interpret `TZ=EST5EDT` as having DST always in effect
On Thu, Jun 13, 2024 at 10:01:16AM +0200, Angelo Borsotti wrote:
> @echo-on
> cat f1.txt f1.txt > f1.tmp
> @echo-off
>
> I.e. the command is not entirely displayed.
Yeah. This is what I mentioned originally: set -x does not show
redirections. Ever. There is no workaround for this currently.
A
Dear all,
the solution to show commands with "set -x" has, however, a flow: it
does not show properly commands that contain redirections. E.g., let
tmp.sh be:
#!/bin/bash
shopt -s expand_aliases
alias @echo-on='set -x'
alias @echo-off='{ set +x; } 2>/dev/null'
PS4=
@echo-on
cat f1.txt f1.txt > f1
34 matches
Mail list logo
