ah , this might be due to u use it after a bash keyword
1. it doesnt need export cause its already exported
2. if u wanna export , export it
but 3. do PATH='...' or ".." ur string
but not after export or declare
just on its own line
greets
On Tue, Feb 4, 2025, 4:53 AM Zeffie wrote:
> On 2025-02
On Tue, Feb 4, 2025, at 12:03 AM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> On 2025-02-03 23:54, Greg Wooledge wrote:
>
> We are talking about shtty.c
>
> Read the code and figure it out yourself since your so smart.
As the bug reporter, you're the one who has to prove there'
On 2025-02-03 23:54, Greg Wooledge wrote:
We are talking about shtty.c
Read the code and figure it out yourself since your so smart.
Zeffie
On 2025-02-03 23:52, Lawrence Velázquez wrote:
Unbelievable.
Yeah you are. Go read the code and walk away. Clearly you don't have any
more then trolling to contribute.
Zeffie
On Mon, Feb 03, 2025 at 23:37:12 -0500, Zeffie via Bug reports for the GNU
Bourne Again SHell wrote:
> READ THIS
>
> To be more clear here the GNU BASH shell that I tested with is merely
> a test case and the configuration was very harsh :
>
> $ ./configure --prefix=/home/dclarke/local --enable-
On Mon, Feb 3, 2025, at 11:37 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> READ THIS
>
> To be more clear here the GNU BASH shell that I tested with is merely
> a test case and the configuration was very harsh :
>
> $ ./configure --prefix=/home/dclarke/local --enable-threads
On 2025-02-03 23:29, Lawrence Velázquez wrote:
On Mon, Feb 3, 2025, at 11:08 PM, Zeffie via Bug reports for the GNU
Bourne Again SHell wrote:
READ THE BUG REPORT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284513
Yes, let's.
The default FreeBSD bourne shell /bin/sh seems to igno
On Mon, Feb 3, 2025, at 11:08 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> READ THE BUG REPORT
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284513
Yes, let's.
The default FreeBSD bourne shell /bin/sh seems to ignore
the terminal config flag echoctl an
On Mon, Feb 03, 2025 at 23:08:53 -0500, Zeffie via Bug reports for the GNU
Bourne Again SHell wrote:
> READ THE BUG REPORT
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284513
The bug report says:
The default FreeBSD bourne shell /bin/sh seems to ignore the terminal
config flag ech
On 2025-02-03 22:53, Lawrence Velázquez wrote:
The bug report is about FreeBSD ash, not bash.
The bug report is about FreeBSD ash, not bash.
The bug report is about FreeBSD ash, not bash.
The bug report is about FreeBSD ash, not bash.
The bug report is about FreeBSD ash, not bash.
The bug report
On Mon, Feb 3, 2025, at 10:24 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Focus on $BASH_VERSION:
>While you argue about testing for $BASH_VERSION, this point isn’t
> central to the bug report. The issue is about terminal reinitialization
> in sh‑mode (when Bash is inv
On 2025-02-03 22:19, microsuxx wrote:
~ $ p=~:~:~ ; declare -p p
declare --
p="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home"
~ $ cp $( type -P bash ) sh
~ $ ./sh
sh-5.2$ x=~:~:~:
sh-5.2$ declare -p x
declare --
x="/data/data/com.termux/files
Lawrence Velázquez,
To clarify, several points in your response appear to miss the mark on
the core issue of the bug report:
Focus on $BASH_VERSION:
While you argue about testing for $BASH_VERSION, this point isn’t
central to the bug report. The issue is about terminal reinitialization
in
~ $ p=~:~:~ ; declare -p p
declare --
p="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/data/data/com.termux/files/home"
~ $ cp $( type -P bash ) sh
~ $ ./sh
sh-5.2$ x=~:~:~:
sh-5.2$ declare -p x
declare --
x="/data/data/com.termux/files/home:/data/data/com.termux/files/home:/d
dude u cant whitelist it or smth .. ?
On Tue, Feb 4, 2025, 3:00 AM Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Thank you for your thoughts. While I appreciate your perspective on DKIM
> and spam filtering, I expect the list maintainers to handle these issues
> properly. I've b
with all i mean freebsd ones
On Tue, Feb 4, 2025, 4:12 AM microsuxx wrote:
> look dude ,
> i looked at the link flying by
> by long texts and no clear examples this n that
>
> try , providing _all_ _exact_ cmds to reproduce it , in once , here and on
> ur other list
>
> then shtuff may change ..
look dude ,
i looked at the link flying by
by long texts and no clear examples this n that
try , providing _all_ _exact_ cmds to reproduce it , in once , here and on
ur other list
then shtuff may change ..
greets
On Tue, Feb 4, 2025, 12:44 AM Zeffie via Bug reports for the GNU Bourne
Again SHel
On Mon, Feb 3, 2025, at 8:52 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Every technical comment deserves thoughtful consideration. When a
> maintainer responds without reading and understanding the posts, or
> worse, dismisses them with drivel (as I found Lawrence’s respo
Thank you for your thoughts. While I appreciate your perspective on DKIM
and spam filtering, I expect the list maintainers to handle these issues
properly. I've been running mail servers since the 1990s, so I
understand the complexities involved. Even if many messages on the list
aren’t signed
On 2025-02-03 20:11, Lawrence Velázquez wrote:
I'm sorry you didn't get the response you expected, and you're
free to express your disagreements, but as a guest here you've
been incredibly rude.
After two uncalled-for responses that have wasted my time, I must say
that this behavior is complet
Date:Mon, 03 Feb 2025 19:00:28 -0500
From:Zeffie via Bug reports for the GNU Bourne Again SHell
Message-ID: <875b2e87e5d847a4aa04ba2b31bec...@zeffie.com>
| To whom it may concern,
That is most probably not anyone on this list - you'd need to contact
the list maint
On Mon, Feb 3, 2025, at 5:43 PM, Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Thank you for taking the time to not review the FreeBSD bug report (Bug
> 284513) in full before responding. Your willingness to speculate on
> behaviors without testing in the relevant environment is
To whom it may concern,
Bash has long maintained a legacy feature whereby, in interactive
sessions, a literal tilde (`~`) at the start of a `PATH` element (e.g.,
`~/bin`) is expanded to the user’s home directory at the time a command
is executed. While this behavior can sometimes “help” users
To whom it may concern,
I wanted to bring to your attention that the bash-bug mailing list
messages are being marked as spam by our spam filtering. The debug
headers indicate an "Invalid DKIM signature" which appears to be causing
the posts to be flagged.
This is particularly concerning beca
On 2025-02-03 18:14, microsuxx wrote:
i suggest u be some kinder ..
I have a long history on various Linux forums and always strive to
remain polite and respectful. However, I have a very low tolerance for
practices like top posting and responses that seem nonsensical or
dismissive. As some
On Mon, Feb 03, 2025 at 17:43:38 -0500, Zeffie via Bug reports for the GNU
Bourne Again SHell wrote:
> 1. `echo $BASH_VERSION` is Irrelevant
> You seem to have completely misunderstood the context of the bug report. The
> command:
>
> ```sh
> echo $BASH_VERSION
> ```
> is entirely irrelevant in t
i suggest u be some kinder ..
On Mon, Feb 3, 2025, 11:43 PM Zeffie via Bug reports for the GNU Bourne
Again SHell wrote:
> Thank you for taking the time to not review the FreeBSD bug report (Bug
> 284513) in full before responding. Your willingness to speculate on
> behaviors without testing in
Thank you for taking the time to not review the FreeBSD bug report (Bug
284513) in full before responding. Your willingness to speculate on
behaviors without testing in the relevant environment is duly noted and
much appreciated.
Now, let’s break down the issues with your response:
1. `echo $
On Mon, Feb 3, 2025, at 2:57 PM, dale.wor...@comcast.net wrote:
> Within that context, if an element of PATH contains a '~' character, you
> don't expect that to cause execution requests to look in your home
> directory, because '~' isn't the name of your home directory.
Yes, that was the whole po
On 2/3/25 12:21 PM, Zeffie via Bug reports for the GNU Bourne Again SHell
wrote:
Please show the scenario where bash isn't preserving the ECHOCTL flag if
it's present. The function you're modifying below changes the settings in
a termios struct that holds the current terminal settings. If the ECH
Subject: Re: Tilde is expanded in $PATH, inconsistent behavior
Date: Mon, 27 Jan 2025 15:21:06 -0500
Keith Thompson writes:
> The "Tilde Expansion" section of the bash manual does talk about
> using '~' when setting $PATH, but that applies only when setting
> it, not when using a $PAT
sanjay kumar via Bug reports for the GNU Bourne Again SHell
writes:
Somehow all the line breaks in your report were lost. As I reconstruct
it, you wrote:
> cat test.sh
#!/bin/bash
echo "argv[0] = ${0}"
echo "argv[1] = ${1}"
echo "argv[2] = ${2}"
echo "count = ${#}"
=
Please show the scenario where bash isn't preserving the ECHOCTL flag
if
it's present. The function you're modifying below changes the settings
in
a termios struct that holds the current terminal settings. If the
ECHOCTL
flag is set there, bash won't change it.
Further, the function you're mod
On 2/1/25 8:03 PM, Zeffie via Bug reports for the GNU Bourne Again SHell wrote:
Hello,
This patch is submitted for consideration only. It addresses an issue in
sh‑mode where Bash fails to preserve the user-configured echoctl flag.
Please show the scenario where bash isn't preserving the ECHOC
34 matches
Mail list logo
