et
-u` instances optimal by default even just by theory. That way the
number of added exceptions would only matter to people who care about
using `set -u`.
--
konsolebox
diff --git a/subst.c b/subst.c
index 251eafaf..5e906c10 100644
--- a/subst.c
+++ b/subst.c
@@ -10142,9 +10142,9 @@ parameter_br
tributes is
simpler.
--
konsolebox
Changing "c == '@'" to "c == '@' && !want_attributes" in line 10145 of
subst.c seems enough to fix it.
--
konsolebox
diff --git a/subst.c b/subst.c
index 251eafaf..9ee816e0 100644
--- a/subst.c
+++ b/subst.c
@@ -10142,7 +10142,7 @@ parameter
3.0(1)-beta (x86_64-pc-linux-gnu)
--
konsolebox
On Tue, Aug 6, 2024 at 3:09 PM konsolebox wrote:
>
> On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey wrote:
> >
> > On 7/18/24 4:44 PM, konsolebox wrote:
> > > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote:
> > >>
> > >> On 7/11/24 3:51 AM,
On Thu, Jul 25, 2024 at 9:10 PM Chet Ramey wrote:
>
> On 7/18/24 4:44 PM, konsolebox wrote:
> > On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote:
> >>
> >> On 7/11/24 3:51 AM, konsolebox wrote:
> >>> On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote:
On Thu, Jul 18, 2024 at 11:02 PM Chet Ramey wrote:
>
> On 7/11/24 3:51 AM, konsolebox wrote:
> > On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote:
> >> and the BASH_SOURCE
> >> absolute pathname discussion has been bananas, so that's not going in any
> &
On Thu, Jul 11, 2024 at 4:08 AM Chet Ramey wrote:
> and the BASH_SOURCE
> absolute pathname discussion has been bananas, so that's not going in any
> time soon.
Maybe just create BASH_SOURCE_REAL instead to avoid the gripes.
https://gist.github.com/konsolebox/d9fb2fadd2b8b13d96
or source are full paths. But I
think it's better to be consistent. It comes with fewer surprises and
usage rules.
--
konsolebox
On Mon, Jul 1, 2024 at 10:56 PM Chet Ramey wrote:
>
> On 6/26/24 5:59 AM, konsolebox wrote:
> > On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey wrote:
> >>
> >> On 6/19/24 6:12 PM, konsolebox wrote:
> >>
> >>> Alternatively, have BASH_SOURCE always
en at
the same time, unnecessarily allowing more room for unexpected errors.
Isn't that worse? It doesn't matter if bash seamlessly allows
multiple recursion-generated pipes or not.
Your use case at some point may be practical but it's the one that
should be questioned first. Storing output is the sane choice in most
cases.
--
konsolebox
On Sat, Jun 29, 2024 at 10:23 PM Zachary Santer wrote:
>
> On Sat, Jun 29, 2024 at 4:40 AM konsolebox wrote:
> >
> > You can avoid pipe recursions by storing the output first in an array.
>
> So is this a known issue?
I don't know. I haven't really checked y
entry_path}/${path}" || return
fi
...
done
cd -- "${starting_PWD}"
-
You can also just use a 'die' function if cleanups aren't needed.
Anything is valid in a contained code.
--
konsolebox
oment they are
accessed.
I still prefer the simpler one however, which is to just assign real
paths to BASH_SOURCE by default.
--
konsolebox
On Tue, Jun 25, 2024 at 11:14 PM Chet Ramey wrote:
>
> On 6/19/24 6:12 PM, konsolebox wrote:
>
> > Alternatively, have BASH_SOURCE always produce real physical paths
> > either by default or through a shopt.
>
> This is the best option. I don't think changing ba
means you have to store
the context directories to another list.
--
konsolebox
paths
either by default or through a shopt.
Any additional feature that doesn't allow loading a script relative to
the caller without external help is practically useless.
--
konsolebox
rting `-m`.
It is mostly convenient if you only need to load a single script. For example:
source "$(realpath -m "${BASH_SOURCE}/../../lib/script.bash")" || exit
--
konsolebox
t time
they are called. For example they can call a script containing the
proper implementation with heavier code. Or simplify themselves
depending on the environment or the available tools they detect at
first run.
--
konsolebox
On Tue, May 21, 2024 at 4:10 AM Chet Ramey wrote:
>
> On 5/20/24 3:39 AM, konsolebox wrote:
>
> > It's rare for a topic about adding an import/include function to get
> > so much attention like this I think it's time Bash takes the
> > opportunity t
this I think it's time Bash takes the
opportunity to implement it and hopefully properly.
--
konsolebox
On Sun, May 19, 2024 at 7:01 AM Matheus Afonso Martins Moreira
wrote:
>
> > The issue is that what you want, and what I want,
> > and what konsolebox wants (and everyone else)
> > are all slightly different.
>
> The option solution which I proposed is not really in op
Here's an output from devel branch bash and 5.2.26:
$ bash-9 -c 'echo "$BASH_VERSION"; x="abc#xyz"; echo "${x/\#}"'
5.3.0(1)-alpha
abc#xyz
$ bash-5.2.26 -c 'echo "$BASH_VERSION"; x="abc#xyz"; echo "${x/\#}"'
5.2.26(1)-release
abcxyz
--
konsolebox
On Sat, May 18, 2024 at 9:18 AM Martin D Kealey wrote:
> On Thu, 16 May 2024 at 22:50, konsolebox wrote:
>>
>> On Thu, May 16, 2024 at 4:59 PM Martin D Kealey
>> wrote:
>> > As I understood your counter-proposal, it would result in this:
>> > * ./a and
I also uploaded a copy of the script and the patch to gist:
https://gist.github.com/konsolebox/a908cf13e511abdf05daec89a9cbdd8d
--
konsolebox
/shell.h
index b9d259a5..721e0086 100644
--- a/shell.h
+++ b/shell.h
@@ -246,3 +246,5 @@ extern void uw_restore_parser_state (void *);
extern sh_input_line_state_t *save_input_line_state (sh_input_line_state_t *);
extern void restore_input_line_state (sh_input_line_state_t *);
+
+extern char *sh_physpath (char *, int);
The recommended way to use the script is by placing it to a common PATH location
like /usr/local/bin and name it as 'source-extensions'.
Scripts can import it by simply calling `source source-extensions` before
other source commands.
Consistency before simplicity.
--
konsolebox
On Thu, May 16, 2024 at 4:59 PM Martin D Kealey wrote:
> On Wed, 15 May 2024 at 16:33, konsolebox wrote:
>>
>> On Wed, May 15, 2024 at 7:16 AM Martin D Kealey
>> wrote:
>>
>> > I'm concerned that doing both would introduce an entirely new dichotomy
>
;?
No. `source` already searches PATH when ./ isn't provided. That's
already intuitive.
In C, you don't specify ./ as well when referring to relative paths in
#include. No one should ever get used to using ./ when referring to
relative paths.
--
konsolebox
should be considered explicit so if
you want lib/foo.bash to load relative to BASH_SOURCE_PATH's ".", just
specify "lib/foo.bash".
--
konsolebox
On Tue, May 14, 2024 at 2:09 PM Martin D Kealey wrote:
>
> I wholeheartedly support the introduction of BASH_SOURCE_PATH,
ear-old framework too. Thank you very much. :)
https://loader.sourceforge.io/overview/
--
konsolebox
On Mon, Feb 21, 2022 at 2:23 AM konsolebox wrote:
>
> Commonly `readarray -t`, a pipe, and a subshell is used to get the
> results of compgen but this has two problems:
>
> - It uses a pipe and a subshell
> - Values having newlines will be split
>
> Those can be preven
On Mon, Jun 21, 2021 at 11:34 PM Chet Ramey wrote:
> I'll consider it. It's low priority right now.
Hello Chet, I just saw this implemented in 5.3. Just want to say
thanks a lot!! I extremely appreciate it.
--
konsolebox
This doesn't look right to me:
# export BASH_ARGV0=fdsafasfas
# bash
# echo "$BASH_ARGV0|$0"
fdsafasfas|fdsafasfas
# echo $BASH_VERSION
5.2.0(1)-release
--
konsolebox
ction name is same as script) or
'utils..' since the dot is allowed in Bash. For the
global variables used in each script, I have them all capitalized and
prefixed with the name of the "namespace", like
"UTILS__". It risks conflict with global and builtin
variables but adds easy distinguishability vs. just using lowercase
letters prefixed with an underscore. Optionally an underscore can be
prefixed to avoid the conflict but I haven't really needed it so far
besides on a few shared (just, probably) ones.
I also do have an extended "include" function that accepts wildcards
best used for loading dynamic yet managed sub-scripts.
--
konsolebox
On Sat, Feb 19, 2022 at 9:34 PM Chet Ramey wrote:
> Thanks for the report. This is the result of needing to clean up parser
> state before recursively calling it to parse the command substitution.
Just tested devel. This one's fixed as well.
--
konsolebox
On Mon, Mar 21, 2022 at 7:11 PM Chet Ramey wrote:
> Isn't this the same as
>
> https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00038.html ?
>
> That's already fixed.
I'm sorry I didn't check. Yes it's already fixed.
--
konsolebox
ckspace to be typed to be triggered. I can't
reproduce it with 5.1.4 and 5.1.16. All tested versions have their
bundled readlines compiled with them.
--
konsolebox
On Mon, Mar 7, 2022, 23:16 Chet Ramey, wrote:
> On 2/26/22 2:01 PM, konsolebox wrote:
>
> > I think an option like 'escape' that simply escapes COMPREPLY
> > values when used for completion and doesn't compare it to existing
> > filesystem objects will be
On Fri, Feb 25, 2022 at 2:46 PM Chet Ramey wrote:
>
> On 2/25/22 3:29 AM, konsolebox wrote:
> > On Mon, Feb 21, 2022 at 4:32 PM Chet Ramey wrote:
> >> What does `properly quoted' mean here and how does it differ from the
> >> quoting you get when you force c
On Fri, Feb 25, 2022 at 8:29 AM konsolebox wrote:
> What I need more is an option that allows replacing the current
> word including the quote (', ", or $') that begins it with the result
> as is rather than appending the result to the quote.
... because the result is alr
lash to the result when the result matches a
directory. For example, "test" which refers to a task becomes
"test/".
--
konsolebox
be properly quoted, this manual quoting hacks wouldn't be needed.
--
konsolebox
Commonly `readarray -t`, a pipe, and a subshell is used to get the
results of compgen but this has two problems:
- It uses a pipe and a subshell
- Values having newlines will be split
Those can be prevented if another option is added. E.g.:
compgen -O array_var ...
--
konsolebox
ns it and exits well.
Compiling it with a safer flag like `-ggdb3 -O -pipe` didn't help.
--
konsolebox
On Mon, Feb 7, 2022, 00:31 Chet Ramey, wrote:
> From CHANGES:
>
> ...
Well I'm glad. Thanks again!
--
konsolebox
On Thu, Dec 30, 2021 at 4:35 PM Chet Ramey wrote:
> Let's try it. Thanks for the report.
It seems to be already fixed in 5.2-alpha (thanks), but I can't see it
mentioned in the changelog. Can you kindly confirm if it really is?
--
konsolebox
ta that is needed.
> That would be reasonable, the \x nonsense (the PSx escapes) aren't.
Thanks for the details. I at least agree with not using \w and \W
here if anyone wants to escape literal escape sequences, or wait till
bash adds a generous feature that escapes any valid terminal code.
--
konsolebox
On Tue, Jan 25, 2022, 06:24 Robert Elz, wrote:
> Date:Tue, 25 Jan 2022 05:45:23 +0800
> From: konsolebox
> Message-ID: <
> cajnmqwbvrbdijqcu8+oo0gvic7onew8nkv4djfyy3o5eepm...@mail.gmail.com>
>
> | As for me whatever it is, it should be done
ogether with Chet's and Greg's mail; All around good and
> reasonable things said by people I trust to say sensible things about
> the shell. Thanks. I'll stand down from my "you need to do something
> right now" position.
>
> Take care,
>
As for me whatever it is, it should be done consistently and with no
compromise. No matter how "slightly broken" it is or no matter unlikely it
is to occur it should be fixed. Post filename expansion or population
processes should not make any interpretation of the expanded filenames in
whatsoever manner.
--
konsolebox
On Thu, Dec 30, 2021 at 4:35 PM Chet Ramey wrote:
>
> On 12/27/21 11:37 PM, konsolebox wrote:
> > On Thu, Apr 8, 2021, 06:56 konsolebox, > <mailto:konsole...@gmail.com>> wrote:
> >
> > On Thu, Apr 8, 2021 at 2:44 AM Chet Ramey >
On Mon, Jun 21, 2021, 23:34 Chet Ramey, wrote:
> On 6/16/21 2:04 AM, konsolebox wrote:
>
> > Thanks, that worked well. Is there a chance a feature that would
> > allow this be defaulty implemented in the next version? If yes, what
> > would be the strategy
On Thu, Apr 8, 2021, 06:56 konsolebox, wrote:
> On Thu, Apr 8, 2021 at 2:44 AM Chet Ramey wrote:
> > Indirection does not check whether or not the variable it's indirecting
> > is $@/$* or ${array[@/*]}. It simply goes by the return value.
>
> It looks like it can
cripts more portable, which means other
> implementors
> are under no pressure to copy the feature...Implemented optimisations
> for the standard shell syntax simply work, and improve performance, while
> still allowing the script to work anywhere.
>
I'm not really concerned about portability for this. Bash has always made
its own fruitful implementations.
--
konsolebox
To Chet: Any thoughts on this?
--
konsolebox
ds to be documented. It makes
use of a single parameter but interprets its values differently.
Anyway at least I now know the behavior is intended, so I don't really
mind how this goes.
--
konsolebox
On Wed, Dec 22, 2021 at 4:07 AM Greg Wooledge wrote:
> I would recommend not using set -u.
> Especially
> when you need to support multiple bash versions, or even multiple shells.
It's still useful during development stages.
--
konsolebox
ociative array
variable that can contain the name of the completion as the key and
the value as the word break characters.
--
konsolebox
On Fri, Dec 17, 2021 at 7:13 PM Chet Ramey wrote:
>
> On 12/17/21 2:00 PM, konsolebox wrote:
> > On Sat, Dec 18, 2021, 00:49 Chet Ramey, wrote:
> >> Well, the documentation says the line gets broken into words the way
> >> readline does it, and r
nce on how a separator is kept
like rl_special_prefixes but none of them seems to have anything to do
with the space character.
--
konsolebox
Nevermind I found a way. The trick is to enable nospace by default
and add space manually to only result when result is 1 and is valid.
--
konsolebox
t appearing in the completions.
--
konsolebox
n't spaces are also passed as an
argument and stored in COMP_WORDS. This surprised me a bit, and I
think it would be helpful if this behavior gets documented as well.
Tested with 5.1.12.
--
konsolebox
On Wed, Jun 2, 2021, 10:27 konsolebox, wrote:
> On Tue, May 25, 2021 at 4:36 AM Chet Ramey wrote:
> >
> > On 5/22/21 8:29 AM, konsolebox wrote:
> > > `read -e` doesn't recognize custom completions (at least on my basic
> > > observations). For exampl
On Tue, May 25, 2021 at 4:36 AM Chet Ramey wrote:
>
> On 5/22/21 8:29 AM, konsolebox wrote:
> > `read -e` doesn't recognize custom completions (at least on my basic
> > observations). For example, if I enable `complete -IW 'someword
> > another-word'`,
utocomplete the commands that are accepted.
Perhaps adding a shell option that enables this or another option to
read like -E would be sensible.
--
konsolebox
On Fri, Apr 30, 2021 at 4:09 PM Robert Elz wrote:
>
> Date:Fri, 30 Apr 2021 14:53:58 +0800
> From:konsolebox
> Message-ID:
>
>
> | {{ }} - Similar to { }, but runs like a function so variables can be
> | declared local
>
> From
global variable when unsetting an
iterator in an initialization script to keep the variables clean, even
just by theory.
--
konsolebox
I'll just skip that as I would also have to modify
other declarations for consistency. I think the code is already good
enough for a proof of concept at least.
--
konsolebox
unsigned int flags; /* Flags associated with this word. */
> `y.tab.c' is automatically generated from `parse.y'. You should edit
> `parse.y' instead of `y.tab.c'
I also modified parse.y. All changes made so far can be seen in
https://git.io/JOam0.
Thanks for the tips.
--
konsolebox
aval = (char *)xmalloc (1);
aval[0] = '\0'; /* like do_assignment_internal */
- free_aval = 1;
}
bind_assoc_var_internal (var, h, akey, aval, flags);
- if (free_aval)
- free (aval);
+ free (aval);
}
}
--
konsolebox
also available in
https://github.com/konsolebox/bash/tree/skip_expansion_of_valid_array_refs_in_unset.
The patch is applied against the latest commit (f3a35a2d60) in master
branch. The changes can be conveniently compared in
https://git.io/JOgrE.
The solution allows the following tests to pass. A
t going to go that way without much better reasons than I've seen
> so far.
There's less reason to choose a complicated solution that adds
thinking overhead, adds inconsistencies and breaks scripts.
Making unset skip default word expansion on tokens that pass
valid_array_reference () is much simpler.
--
konsolebox
On Fri, Apr 16, 2021 at 12:10 AM Chet Ramey wrote:
> > I actually agree with konsolebox that assoc_expand_once for unset
> > shouldn't be defaulted. The option `assoc_expand_once' is incomplete
> > in the sense that the behavior of `a[@]' and `a[*]' are
ak scripts.
The only change I'd want is have `unset 'a[@]'` only unset the
elements and not the array itself.
--
konsolebox
s or external commands is a function.
Try `type which`.
--
konsolebox
my_function {
local my_function__a
another_function my_function__a
}
This solution applies to namerefs, indirections and evil eval.
Keeping the passed references sane is up to the scripter.
--
konsolebox
On Fri, Apr 9, 2021 at 8:17 AM konsolebox wrote:
> It's a definite shell feature despite lacking internal sanity checks.
*despite having limited
--
konsolebox
king internal sanity checks.
--
konsolebox
On Fri, Apr 9, 2021 at 3:21 AM Chet Ramey wrote:
>
> On 4/6/21 11:42 AM, konsolebox wrote:
>
> > Or maybe just completely avoid this new behaviors and allow another
> > way to unset an element of an array.
> >
> > a[$key]=()
> > a[@]=()
>
> While thi
On Fri, Apr 9, 2021 at 2:19 AM Chet Ramey wrote:
> What is your end goal? To run the same script on different versions of
> bash, or something else?
Nevermind. I overthinked.
--
konsolebox
rrayref = 1;
+ }
+}
+ else if (valid_array_reference (name, 0))
{
int qflags;
char *t;
--
konsolebox
On Wed, Apr 7, 2021 at 9:25 PM Chet Ramey wrote:
>
> On 4/5/21 4:45 PM, konsolebox wrote:
> > set -u
> > array=()
> > __ref=array[@]
> > : "${array[@]}" # Reports nothing
>
> This is a special case, mirroring the special case that POSIX carved
the clearest example I can give
is Java's LinkedHashMap.
--
konsolebox
On Wed, Apr 7, 2021 at 12:20 AM Ilkka Virta wrote:
> What konsolebox said about a[$k]=() works in my Zsh for indexed arrays, but
> not associative ones.
> (It replaces an array slice, so can also be used to insert elements in the
> middle.)
Bash can adopt this. Also if Bash coul
of the arguments of the `unset' builtin is the cleanest way
> to solve the problem of `key=@; unset -v a[$key]'.
Or maybe just completely avoid this new behaviors and allow another
way to unset an element of an array.
a[$key]=()
a[@]=()
I think a shell already does this. Not sure if it's from ksh, zsh, or pdksh.
--
konsolebox
d don't expand the
referenced target themselves.
${!__ref} is synonymous to ${array[@]}, not ${${array[@]}}.
This is why you can do other parameter expansion features like
${!var+.} ${!var@a}.
--
konsolebox
verything or nothing. Unbound variable errors should not apply to it.
--
konsolebox
On Tue, Apr 6, 2021 at 9:57 PM Alex fxmbsw7 Ratchev wrote:
>
> arr=( ) implies no [0]=
Also `arr=()` does not imply `arr[0]=`. `arr[0]` remains unset and not
assigned to any. Not even an empty string.
--
konsolebox
On Tue, Apr 6, 2021 at 9:57 PM Alex fxmbsw7 Ratchev wrote:
>
> arr=( ) implies no [0]=
arr[0] is not exactly being referenced here.
--
konsolebox
On Mon, Apr 5, 2021 at 9:44 PM Chet Ramey wrote:
>
> On 4/1/21 3:02 PM, konsolebox wrote:
>
> >> To do what, exactly?
> >
> > To keep this working in both behaviors.
> >
> > declare -A a
> > key='$(echo foo)'
> > a[$key]=1
> &
le functions to have less versions.
The detection of unbound variables seem to have become more reasonable
since 5.0 and I hope it gets improved further. I don't use set -u in
older bash and it's only for development mode.
--
konsolebox
doesn't generate that error on macOS, for instance, which has /dev/fd.
Thanks. I'll take note of it for future reference.
--
konsolebox
gt;/dev/tcp/host/port'
Nice strategies.
--
konsolebox
s like this does the same:
# echo a | tee /dev/fd/4 4>/dev/tcp/host/port
# echo a | ( tee /dev/fd/4 ) 4>/dev/tcp/host/port
The workaround is to use process substitution and cat:
# echo a | tee >( cat > /dev/tcp/host/port )
Tested in 5.1.4.
--
konsolebox
2150. They are labeled as "Reserved words".
--
konsolebox
with them as well. This should have been explicitly allowed by the
shell. It's highly doable even if they are followed with
non-keywords. Just look at awk's syntax.
--
konsolebox
reserved words themselves just like () and {} as they can be
used multi-line but they aren't allowed to be adjacent to else et al
without a semicolon. [[ ]], (( )), {}, and () are practically just
commands with first-class parsing that consistently have to end with a
semicolon if followed by another reserved word or command.
--
konsolebox
t; rule.
>
> The right question would be why '} else' works.
Indeed. This inconsistency should be fixed and prevent people from
using it wrong. `}; else` should work but not `} else` just like how
`{ :; } :` doesn't.
--
konsolebox
On Fri, Apr 2, 2021 at 3:02 AM konsolebox wrote:
>
> On Fri, Apr 2, 2021 at 2:56 AM Chet Ramey wrote:
> >
> > On 4/1/21 2:55 PM, konsolebox wrote:
> >
> > > So to keep compatibility, would this be the right way?
> > >
> > > if [[ BASH_VERSINFO
On Fri, Apr 2, 2021 at 2:56 AM Chet Ramey wrote:
>
> On 4/1/21 2:55 PM, konsolebox wrote:
>
> > So to keep compatibility, would this be the right way?
> >
> > if [[ BASH_VERSINFO -ge 6 || BASH_VERSINFO -eq 5 && BASH_VERSINFO -ge 2 ]];
> >
1 - 100 of 216 matches
Mail list logo
