On 2019/07/29 22:49, k...@munnari.oz.au wrote:
> | I didn't see this come back from the list and it was sent
> | 45 minutes ago (vs. other emails of mine that have come
> | back in under a minute).
> | Did anyone else see it?
>
> Yes. The original appeared (before this repeat). Avoid
On 2019/09/30 14:39, Grisha Levit wrote:
> A few of the recently-added shopt options aren't getting reset when
> running a shebang-less script, this should fix it up:
>
Suppose the shebang-less script is being run by an earlier version
of bash. Won't the new patch radically change the behavior
On 2019/10/01 05:41, Greg Wooledge wrote:
> On Tue, Oct 01, 2019 at 04:14:00AM -0700, L A Walsh wrote:
>
>> On 2019/09/30 14:39, Grisha Levit wrote:
>>
>>> A few of the recently-added shopt options aren't getting reset when
>>> running a s
On 2019/10/02 03:49, Ilkka Virta wrote:
>
> If the execl() function fails due to an error equivalent to the
> [ENOEXEC] [...] the shell shall execute a command equivalent to
> having a shell invoked with the pathname resulting from the
> search as its first op
On 2019/10/31 21:54, Patrick Blesi wrote:
> I'm looking for a hybrid between single quotes and a here doc or here
> string.
>
> The main use case is for accepting arbitrary user-specified text. I would
> like to wrap this text in single quotes so as to prevent any variable
> expansion or interpreta
On 2019/11/02 23:31, Eli Schwartz wrote:
> On 11/3/19 1:08 AM, L A Walsh wrote:
>
>> I can't say for certain, but is there any reason why this wouldn't
>> work? I am probably missing something obvious, but this would seem to
>> solve your problem, no?
>
On 2019/11/09 04:49, Robert Elz wrote:
> There's also
>
> The special characters '.', '*', '[', and '\\'
> (, , , and ,
> respectively) shall lose their special meaning within a bracket
> expression.
>
Is this really what the standard says, because '\\' is not a char
FWIW, Andreas's description really was sufficient...
On 2019/11/07 12:18, Daniel Colascione wrote:
>>> statuses? This information is practically free to collect.
>>>
>> Because by the time you gather this information, the command has already
>> been saved completely.
>>
>> There have been various proposals to extend the timestamp with addition
On 2019/11/25 07:05, wrote:
> # As you see, now everything works as expected i.e. the issue seems
> # to be in the way readline is handling multibyte invisible characters
> # in a prompt, *probably* in the rl_redisplay() function.
>
Multi-byte or not, invisible characters need to
On 2019/11/25 12:02, Chet Ramey wrote:
> On 11/24/19 7:35 AM, Ulrich Mueller wrote:
>> Description:
>> In a non-interactive non-posix-mode shell, saving the output of
>> "shopt -p -o" and restoring it will unset the expand_aliases option.
>>
>
> It seems like setting posix mode when it's alrea
On 2019/12/02 07:04, pepa65 wrote:
it would be nice to be able to omit 'do'.
like:
set -- 1 2 3
for i
{ echo $i
}
1
2
3
or:
for i;{ echo $i;}
1
2
3
On 2019/12/06 14:14, Chet Ramey wrote:
Seems very hard to print out that backquote though. Closest I got
was bash converting it to "''":
read -r -a a< <(printf "%q " {Z..a})
my -p a
declare -a a=([0]="Z" [1]="\\[" [2]="''" [3]="\\]" [4]="\\^" [5]="_"
[6]="\\\`" [7]="a")
#2 is where backsl
On 2019/12/12 13:01, Ilkka Virta wrote:
On 12.12. 21:43, L A Walsh wrote:
On 2019/12/06 14:14, Chet Ramey wrote:
Seems very hard to print out that backquote though. Closest I got
was bash converting it to "''":
The backquote is in [6], and the backslash disa
On 2019/12/12 19:03, Eli Schwartz wrote:
On 12/12/19 9:57 PM, L A Walsh wrote:
On 2019/12/12 13:01, Ilkka Virta wrote:
On 12.12. 21:43, L A Walsh wrote:
The backquote is in [6], and the backslash disappears, you just get
the pair of quotes in [2] because that's how prin
On 2019/12/13 10:42, Greg Wooledge wrote:
On Fri, Dec 13, 2019 at 10:25:15AM -0800, L A Walsh wrote:
I would assert that for the characters returned by a range that has
metacharacters in it, the metacharacters SHOULD be quoted or they will not
appear in the output.
There's a l
On 2019/12/14 15:12, Robert Elz wrote:
From:L A Walsh
| it could break existing scripts that
Scripts _/should /_not be using brace expansion in the first place,
--
"Should" is about wishful thinking, not reality. What you or I
think "should&
On 2019/12/16 08:39, Greg Wooledge wrote:
On Sat, Dec 14, 2019 at 02:48:16AM -0800, L A Walsh wrote:
On 2019/12/13 10:42, Greg Wooledge wrote:
There's a larger issue to be addressed first. The man page says,
[...]
sary. When characters are supplied, the expression ex
On 2019/12/18 11:46, Greg Wooledge wrote:
To put it another way: you can write code that determines whether
an input character $c matches a glob or regex like [Z-a]. (Maybe.)
But, you CANNOT write code to generate all of the characters from Z to a
This generates characters from decimal 8300
On 2019/12/21 22:38, Eli Schwartz wrote:
On 12/20/19 7:35 PM, L A Walsh wrote:
⁰⁴⁵⁶⁷⁸⁹₀₁₂₃₄₅₆₇₈₉
Q.E.D.
Is that sufficient proof?
It's sufficient proof that you're wrong, yes.
If you only knew how to use the tools you have on your machine.
Given the discussion
On 2019/12/23 05:20, Greg Wooledge wrote:
On Fri, Dec 20, 2019 at 04:35:05PM -0800, L A Walsh wrote:=
You can't simply translate $start and $end to single Unicode code point
values, enumerate the Unicode characters between those two points,
and translate those characters back to the u
On 2019/12/23 12:58, Greg Wooledge wrote:
On Mon, Dec 23, 2019 at 12:52:00PM -0800, L A Walsh wrote:
But it wasn't. It was about generating characters between two
characters that were given. In unicode, that would be two code points.
Nothing about enumeration.
Please gi
On 2020/01/17 06:49, Chet Ramey wrote:
On 1/16/20 2:05 PM, Martijn Dekker wrote:
Op 16-01-20 om 17:02 schreef Chet Ramey:
On 1/15/20 10:24 PM, Martijn Dekker wrote:
When alias expansion is enabled for a script in bash native mode,
prefixing POSIXLY_CORRECT=y to any command
On 2020/03/13 07:52, Robert Elz wrote:
That's OK, and at times I have been tempted that way, but it really is
easier to just do
if
then
true_command1
true_command2
else
false_command1
false_command2
I do:
set output
echo ">$1<"
>output<
output=""printf ${1:+-v $1} "%s:%s" 23 myproc
-Bash: printf: ` output': not a valid identifier
for some reason it is regarding the space before $1 in
the printf as part of the variable name.
It doesn't seem to do this on linux (lnx 4.4.12(3), cyg-4.4.12
The 'stat(2)' system call returns an optimal i/o size for files since some
files in addition to being on disks with a 4k sector size (making 128bytes
a slow choice for reads, and a real slow choice for writes), also can be on
a RAID with it's own optimal i/o size.
I think the 'stat(1)' prog shows
there was a linefeed in my source between output="" and the printf.
It's a gmail feature to mangle your input.
On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote:
> On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote:
> > set output
> > output="&q
It's a gmail feature to mangle your input in weird ways when you cut/paste.
the line with 'output=""' is separate from the "printf" line. Sorry.
On Tue, Jun 23, 2020 at 12:30 PM Greg Wooledge wrote:
> On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A
re: IFS... yup. that was it, not sure how it got cleared, but it did.
Thanks for the clue.
As for gmailnecessity creates unfortunate circumstances...having your
main file system (RAID 0) fail, along with your backups (in a separate disk
enclosure, also RAID 0), isn't something that happens ev
But that wouldn't follow the email response instructions of posting your
response above the previous email or lists where attachments are not
allowed. It also requires putting the 'to-be-protected-text' in a separate
file, on the same computer** or on the local computer (depending on which
email s
I wanted to use a map that looked like this:
declare -A switches=([num]=(one two three)), where '(one two three)'
is an associated list. Ideally, I could access it like other arrays:
for types in ${switches[num][@]}; do...
or
switches[num]=(one two three)#gives:
-bash: swit
On 2020/09/06 05:52, Oğuz wrote:
6 Eylül 2020 Pazar tarihinde almahdi yazdı:
How slower find -exec repetitively calling bash -c'' for invoking a
function
inside, compare to pipe repeated
How I read that (dunno if it is right) was:
"How much slower is 'find -exec' than repetit
On 2020/09/01 05:32, Greg Wooledge wrote:
On Tue, Sep 01, 2020 at 02:14:33AM -0700, almahdi wrote:
> How to get last commnda history line number?
as it's pure & directly viable in PS1 env. var.
PS1=`echo \!`
---
Doesn't work if you don't have '!' support (I generally found
'!' more often d
On 8/28/2020 1:00 AM, Gabriel Winkler wrot
> # Causes error
> test=0
> ((test++))
> echo $?
> 1
> echo $test
> 1
>
"((...))" is the "test form" for an integer expression. That means
it will return true if the value of the interior, "...", of "((...))"
is non-zero and return false if ((... == 0)
On 9/2/2020 2:31 AM, almahdi wrote:
As break 2 is disrupting and exiting loop twice,
How is breaking something not somewhat inherently disrupting?
from current and next outer
scope then how to do if any (or as a feature request) to do
/break continue/
that is to break then immediately continu
On 9/8/2020 5:11 AM, Greg Wooledge wrote:
On Sun, Sep 06, 2020 at 01:18:22PM -0700, L A Walsh wrote:
as it's pure & directly viable in PS1 env. var.
PS1=`echo \!`
---
Doesn't work if you don't have '!' support (I generally found
'!' more ofte
On 2020/09/09 11:32, Greg Wooledge wrote:
No. I said PS1='\! ' and that's what I meant. Not some other random
variable.
unicorn:~$ PS1='\! '
502 echo hi
hi
503
===
Thanks for clarifying. That does work for me. I still had
it stuck in my head as having to do with general variable
usage as y
There's got to be an easier way to do this, but not remembering or finding
it:
First tried the obvious:
declare -a ar1=([0]="1" [1]="2" [2]="3" [3]="44")
an=ar1
echo ${#!an[@]}
-bash: ${#!an[@]}: bad substitution
This works but feels kludgy
an=ar1
eval echo \${#$an[@]}
4
I thought the !na
On 2020/10/20 01:29, Andreas Kusalananda Kähäri wrote:
In bash 4.3+, I would manke your "ar" variable a name reference variable
instead:
$ ar1=(1 2 3 44)
$ declare -n ar=ar1
$ echo "${#ar[@]}"
4
Ya, I was trying to use the 'byname' feature for older/wider support...sigh
On 2020/11/13 09:01, Chet Ramey wrote:
On 11/12/20 6:19 PM, Léa Gris wrote:
declare -c to capitalize first character of string in variable
Thanks for the reminder. I keep forgetting to turn this off. It's too late
for bash-5.1, but I have it tagged to flip to disabled by default in
con
On 2020/11/16 11:02, Alex fxmbsw7 Ratchev wrote:
on my way for a new paste
Anytime you start going over multiple lines in an alias, you
need to consider the use of a function, where 'need' would ideally
increase in proportion to the number of lines you are including.
For increased readability,
If I type in ( + are keypresses)
if [[ '' == $'\t' ]]; then echo ok; else echo notok; fi
bash displays:
if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
ok
if I now copy the 'if' line and paste it
if [[ ' ' == $'\t' ]]; then echo ok; else echo notok; fi
notok
if I take the same li
On 2020/12/08 06:28, Greg Wooledge wrote:
The end result is that it's basically impossible to preserve the original
whitespace of your source material across a terminal copy/paste operation.
So don't count on that.
If you use a random terminal to copy/paste, sure, but if you use a
sp
On 2020/12/08 04:40, Greg Wooledge wrote:
On Tue, Dec 08, 2020 at 09:47:05AM +0100, Andreas Schwab wrote:
On Dez 07 2020, Testing Purposes wrote:
From an integer standpoint, I know that 08 (with one leading zero) is the
same as 8.
Nope, it is a syntax error.
In a bash ma
On 2020/12/08 06:07, Chet Ramey wrote:
On 12/7/20 8:02 PM, L A Walsh wrote:
The problem is that bash isn't displaying a 'tab' character where
one was typed.
It's readline and redisplay. Readline expands tabs to spaces using an
internal tab stop of 8. This all
On 2021/01/09 23:52, n952162 wrote:
Hello,
I consider it a bug that bash (and its hash functionality) includes
non-executable files in its execution look-up
But bash doesn't have an execution lookup.
It has a PATH lookup, and a completion lookup (for executables
when appropriate), but the close
On 2021/01/21 11:43, Chet Ramey wrote:
On 1/21/21 11:18 AM, Merijn Verstraaten wrote:
The history command doesn't seem to work when given a FIFO instead of a file. I was trying to load
history from FIFO using either 'history -r <(echo "$hist")' or 'echo "$hist" |
history -r /dev/stdin', but
On 2021/01/21 21:29, William Park wrote:
Since you're dealing with strings, only %s, %c, and
%[] are sufficient.
You can't read numbers in sscanf?
_Might_ be nice to be able to read a float as well
even though it would need to be access/stored as a
string. Would compliment ability to write o
On 2021/01/26 09:08, Chet Ramey wrote:
That's the real question: whether or not `.' should match @(?|.?), even
when dotglob is enabled (and yes, both patterns have to be in there). There
isn't really any other. Since it doesn't match ? when dotglob is enabled,
there's an obvious inconsistency th
Since this "https://tiswww.case.edu/php/chet/bash/POSIX"; doesn't
seem to be version specific, I'm assuming these are
in the latest bash version.
I don't understand the benefit of the differences involving
hashed-commands and recovery behavior. It seemed like these
behaviors may have served a
On 2021/01/31 10:54, Chet Ramey wrote:
On 1/30/21 6:50 PM, L A Walsh wrote:
First behavior: How is it beneficial for bash to
store a non-executable in the command-hash?
Probably not very, but it's not all that harmful. The `checkhash' option
overrides this.
---
Does
On Thu, May 26, 2016 at 3:30 AM, Chet Ramey wrote:
On 5/25/16 12:00 AM, konsolebox wrote:
Bash seems to have gone through a lot of changes/bugs lately
so it would be nice ...[to be]... sure it's stable forthat major version.
There will be at least one, possibly two, more release
can
Chet Ramey wrote:
Think it through. A variable is not set until it has been assigned a
value. Giving a variable an attribute (in this case, the `local'
attribute) without assigning a value means that the variable is still
unset. For example,
Unless it was set in the global cont
I was wanting to print, a true|false type text
based on a boolean.
What first came to mine was using an array holding the
false & true values (in that order) and indexed by the
((value)) as 0=false, !0=true since arithmetic evals
yield true or false depending on whether the expression
evaluat
I was looking at how the 'ldd' command(bash script) on my system and
came across the code usage:
for file do ## about line 138 in my version
...
case $file in
*/* :
;;
*) file=./$file
;;
esac
...
done
It doesn't appear to set the value of file in any of the code
above the 'f
Dennis Williamson wrote:
There's an implied in "$@"
for file in "$@"
Hmmm...interesting,
thanks,
From a very narrow perspective, it doesn't seem very common. ;-)
Re: Chet
---
Yeah saw that... I think my brain blocked that instance out
because it's the sorta the exact opposite of wha
Chet Ramey wrote:
The relevant change was probably the change in the set of commands to
which
`set -e' applies. The (( command (among others) was added to that list
in bash-4.1. The change was the result of Posix changing the semantics
of the errexit option and expanding its scope from simpl
Chet Ramey wrote:
On 8/15/16 6:15 AM, L. A. Walsh wrote:
Chet Ramey wrote:
The relevant change was probably the change in the set of commands to which
`set -e' applies. The change was the result of Posix changing the semantics of
the errexit option and expanding its scope
Greg Wooledge wrote:
On Mon, Aug 15, 2016 at 03:15:13AM -0700, L. A. Walsh wrote:
Calculations shouldn't ever trigger "-e" except for things like
division by 0 (which doesn't trigger it, as the calculation dies
before an return value can be calculated); it's coun
This is a sample, of what I want:
#!/bin/bash -u
assign_var () {
#if declared var; then
var=assigned
#else printf warn about global definition...; fi
}
lvl1 () {
declare var
assign_var
printf "lvl1 var=%s\n" "$var"
}
lvl1
printf "main var after lvl1=%s\n" "${var:-undef}"
Chet Ramey wrote:
Posix made an error in the 1992 version, in that the specification of
set -e was subtly incompatible with historical...
The relevant change was probably the change in the set of commands to which
`set -e' applies. The (( command (among others) was added to that list
in bash-4
Chet Ramey wrote:
+== CHANGES ==
d. Readline's input handler now performs signal processing if read(2) is
interrupted by SIGALRM or SIGVTALRM.
---
It sounds like the ability for signal handlers to be called while
waiting for input has been restored.
h. Use psele
Chet Ramey wrote:
On 9/16/16 1:51 AM, Eric Pruitt wrote:
Bash Version: 4.4
Patch Level: 0
Release Status: release
Description:
I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux*
]];`.
All /proc/*/cmdline include null bytes, and as of Bash 4.4, this
resu
From the below, it sounds like you've fixed the problem disallowing
signal handlers to process signals. SIGWINCH is specifically listed
to use wait methods that allow it to be processed outside of 'read' --
which apparently caused problems such that signal handling was disabled
in reads and not p
Greg Wooledge wrote:
On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote:
Could you change it back or provide a way to suppress "kiddy-scripter"
seatbelts?
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline)
bash-4.4: warning: command substitution: ignored null
Chet Ramey wrote:
On 9/19/16 2:41 PM, Greg Wooledge wrote:
Bash has only three choices that I can think of: it can silently drop the
NUL bytes (4.3 behavior), it can drop ALL of the bytes and return an
error, or it can drop the NUL bytes with a warning (4.4 behavior).
There is a fou
Chet Ramey wrote:
On 9/19/16 12:38 PM, L. A. Walsh wrote:
It sounds like, from the release notes, that allowing real-time processing
of signal handlers in read should no longer be an issue if pselect
is used to before read to allow waiting for and processing of real-time
events before
Chet Ramey wrote:
Don't assume that every use of something like this has to do with /proc.
Here's a representative report:
"I was wondering what would happen if I'd do something like that:
$ foo="$(cat file_containing_ascii_null_byte)"
or faster
$ foo="$(http://www.gnu.org/software/bash/manual
Greg Wooledge wrote:
I probably shouldn't even bother at this point, but morbid curiosity
compels me to foolish ends.
What are you DOING with these files that contain NUL bytes that makes
it permissible to simply drop the NUL bytes on the floor, with no
explicit step like tr -d \\0 to remove t
Ooops -- that script does try to run w/sudo.. forgot about that...
Like I said, fast & dirty
The script is 5 years old. I don't remember any of the
design decisions that went in to it -- so you wanna pick it apart, go
ahead. I am already quite able to do so myself on stuff I wrote
even 3 years ago, often, so 5 years, hey, go for it.
I wasn't even using aliases to help my coding back th
Reuti wrote:
Am 22.09.2016 um 15:23 schrieb Greg Wooledge :
On Wed, Sep 21, 2016 at 11:15:45PM -0400, mobatu...@yahoo.ca wrote:
declare -a "$string" # results in execution of $string
declare -a a=($string)# does not result in execution of $string
This is why you don't u
Ian Kelling wrote:
The docs currently say:
"When a pattern is used for filename expansion, the character '.' at
the start of a filename or immediately following a slash must be matched
explicitly, unless the shell option 'dotglob' is set.
The last bit should be changed to say
unless the sh
Ian Kelling wrote:
I'm not sure your reading it quite right. Chet gets it.
Another way of explaining it is:
dotglob does not affect the files "." and "..".
---
After I saw Chet's response, I sorta got you were referring to the
"exceptions". Thanks.
-l
Daniel Colascione wrote:
One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin
has an old-fashioned non-COW fork, and to add insult to injury,
process creation generally is very slow (~100ms). It pays to eliminate
subshells in that environment.
Given what Cygwin has to work
XiaoBing Jiang wrote:
Thank you for your explain!
#!/bin/bash
(cd /tmp && exec sleep 20) &
echo "end"
Then, instead of having:
$ ./foo
end
$ ps f -t pts/5
PID TTY STAT TIME COMMAND
7287 pts/5Ss 0:00 bash
20165 pts/5R+ 0:00
Daniel Colascione wrote:
On 10/15/2016 12:23 AM, L. A. Walsh wrote:
Daniel Colascione wrote:
One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin
has an old-fashioned non-COW fork, and to add insult to injury,
process creation generally is very slow (~100
Ya know, if you are looking for optimization opportunities, using
a temporary file to communicate between processes rather than
using an actual pipe, is definitely a performance hit --
ESPECIALLY on Cygwin, where you can't even do a "stat" call on
a file without actually opening the file.
I seem
On 4.3 and earlier, at least on arrays, one could have
the illusion of this working w/o complaint -- and returning
0 when the array was 0-len or unset, or the array length,
otherwise:
echo ${#array[@]:-0}
But I note it only seemed to work in arrays, and in 4.4 gets a
syntax error:
echo ${#ar
Eduardo Bustamante wrote:
what's wrong with?:
echo ${#array[@]}
It will return:
- With array=(1 2 3) -> 3
- With array=() -> 0
- With unset array -> 0
- With declare -a array -> 0
Seems to do what you're looking for.
Not when "-u" is set, which I often have on to help catch misspellings
Chet Ramey wrote:
On 10/21/16 5:41 PM, L. A. Walsh wrote:
[previously] one could have the illusion of this working
w/o complaint -- and returning 0 when the array was 0-len
or unset, or the array length, otherwise:
echo ${#array[@]:-0}
But I note it only seemed to work in arrays, and in
Stuart Shelton wrote:
I have some code which evals a configuration file - but before doing so
attempts to validate the content. It does this by taking each potential
keyword from the file and then doing:
if typeset -p | grep -q "^declare -. ${var}$”; then
… to determine whether the keyword
Stuart Shelton wrote:
The cases appear, purely by inspection, to be:
Not declared: trivially, `typeset -p` doesn’t include the value;
Declared (even as local) but unassigned: `typeset -p` includes "declare --
varname";
Declared and assigned: `typeset -p` includes "declare -- varname=‘value’”
Chet Ramey wrote:
On 10/24/16 7:32 PM, L. A. Walsh wrote:
I don't understand the ambiguity. If param= "#obj[@]", then it
is clear to me that the user wants the length of an array named "obj".
Stop there. In something like ${#obj[@]}, `param' is `
Chet Ramey wrote:
Come on, don't be willfully obtuse. You know better than this. Posix mode
doesn't mean "turning it off does everything the way Linda wants."
No, but claiming posix as a backing for features running that are
not running with posix-mode set, is equally obtuse.
Bash is not l
Chet Ramey wrote:
On 10/29/16 2:04 AM, L. A. Walsh wrote:
You can claim a feature is a certain way because posix requires it
when you are operating in posix-only mode.
Not actually true. I can claim bash implements a particular feature the
way bash implements it.
---
True, but
FYI: This works in 4.3.42 (echos "ATT: execute trap function" in both).
Dr. Werner Fink wrote
The trap EXIT not allways executed, see example script
Repeat-By:
Example script
#!/bin/bash
bash -c '
_rm () { echo ATT: Execute trap
Still having probs building bash-4.4 -- trying first, the builtin
version of readline, and on running got:
readline: ~/.inputrc: line 6: history-size=-1: unknown variable name
readline: ~/.inputrc: line 35: completion-prefix-display-length=256:
unknown variable name
readline: ~/.inputrc: line 3
Saw the bit about bash-4.4 changing things to reduce reallocs/copies,
and wondered if you'd thought about rounding up the allocations
to the nearest page size (at least on linux):
Something along the lines of:
Ishtar:tools/bash/readline-7.0> diff -u history.c.orig history.c
--- history.c 2015-12-
Eduardo Bustamante wrote:
I think this is unnecessary, malloc (either the bash malloc in
lib/malloc/malloc.c or the libc provided malloc) should already take
care of requesting memory in page sized chunks.
At least that's what I see here (morecore function):
http://git.savannah.gnu.org/cgit/ba
Chet Ramey wrote:
It's likely that these have been problems for a long time; the code to
warn about unknown variable names is new in readline-7.0.
---
Ah... didn't know that. That's likely all or most of
those.
You can't link bash-4.4 against any readline version except 7.0;
---
Chet Ramey wrote:
On 11/16/16 12:48 PM, L A Walsh wrote:
---
I suspected as much, which makes these settings all the
more important ... these 2 things:
1) How is the location for readline-7.0 specified?
Using the --with-installed-readline argument to `configure'.
---
Chet Ramey wrote:
On 11/16/16 2:26 PM, L A Walsh wrote:
Because that's not what `libdir' is for. Look at the GNU coding standards:
https://www.gnu.org/prep/standards/standards.html#Makefile-Conventions
under the section "Variables for Installation Directories", wh
isabella parakiss wrote:
that's not true https://gist.github.com/fa4efd90376ff2714901e4429fdee734
read successfully reads the data, but then it's discarded by bash
It's discarded by bash because the read doesn't read 10
characters within the time limit. If you use -N 5, you get
you
I was checking to see if an associative array had a member:
echo $BASH_VERSION
4.4.5(1)-release
declare -A requires=([squid]="-d /var/cache/squid/run")
This works as expected:
if [[ ${requires[xxx]:-} ]]; then echo ok; else echo not; fi
not
But this did
Michał Górny wrote:
Hi,
While scanning our systems for executables that are installed u-w, I've
noticed this specific mode is used for bashbug explicitly. Is there
a good reason for doing that?
---
Doesn't it have execute permission? But it seems semi normal
for a system-"executable" t
John McKown wrote:
Not replying for Chet, who will have the definitive answer, I will say
that I, personally, think that is working as designed. ~ 0 (with space
between) is definitely the "not" operator. But without the middle
space, ~0, where there is a white space character in front of the
Chet Ramey wrote:
The short answer is that colon is special to readline: it breaks words for
the readline completion code. If you want to complete filenames beginning
with a colon, either quote the colon or remove colon from
$COMP_WORDBREAKS.
If you're using bash-completion, it may have its own
Is there a way, in bash, to filter stderr and let the
filtered result continue on stderr with the original
stdout being output on stdout?
with prog being the program to filter, and RE_filt being the
filtering expression, conceptually, I wanted to do something
like this:
$prog >&3 2>&1 |grep -v
Dennis Williamson wrote:
http://mywiki.wooledge.org/BashFAQ/047 (search for "stdout intact")
Thanks!
201 - 300 of 361 matches
Mail list logo
