On 2023/05/10 13:13, Eduardo Bustamante wrote:
If you wish for the current shell to continue running after a terminal
resize, then set the signal disposition for SIGWINCH to ignore.
---
You can also display the new size:
alias my=declare
showsize () {\
my s=$(stty size); s="(${s// /x})"
On 2023/03/27 16:52, Greg Wooledge wrote:
Each function has its own private set of positional parameters ("$@" array)
independent of the main script's "$@". If you want the funtion to see
a copy of the script's arguments, you need to pass "$@" to it.
---
Yeah, forgot that. Fact was in
On 2023/03/27 13:05, L A Walsh wrote:
That "$@" is not going to work the way you want it to in the general
case.
---
While I got rid of $@ in some test versions, it was back in
in later version, so that may be the main flaw at this point.
Will need time to clean this mess up...
On 2023/03/27 13:28, Greg Wooledge wrote:
On Mon, Mar 27, 2023 at 01:05:33PM -0700, L A Walsh wrote:
filter_ssh() {
ign0='ssh: connect to host \w+ port 22: Connection refused'
ign1='(agent returned different signature type ssh-rsa)'
ign2='(ssh_exchange_identification: read
On 2023/03/26 10:40, L A Walsh wrote:
This is mostly a test to see if this makes it through to the list.
Something else I tried to
post recently never showed up, and ...
... (sigh)
All showed up at once, once the config was fixed...*sigh*
On 2023/03/27 12:39, Greg Wooledge wrote:
You aren't showing the actual commands that the script is running, so
we have no way to verify that whatever the script is doing is identical
to what you were doing interactively.
Also:
readarray output< <(ssh -n -T "$user@$host" "$@" 2>&1)
Don't know that this is a bug -- there is likely some reason why there's
a difference in interactive vs. script execution. Certainly is annoying!
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but for me ssh generates
1 warning
Don't know that this is a bug -- there maybe some reason why there's
a difference in interactive vs. script execution...certainly isn't helpful
in trying to develop a script though.
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but
Don't know that this is a bug -- there is likely some reason why there's
a difference in interactive vs. script execution. Certainly is annoying!
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but for me ssh generates
1 warning
Don't know that this is a bug -- there is likely some reason why there's
a difference in interactive vs. script execution. Certainly is annoying!
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but for me ssh generates
1 warning
Don't know that this is a bug -- there maybe some reason why there's
a difference in interactive vs. script execution...certainly isn't helpful
in trying to develop a script though.
I'm trying to develop a script to help me run commands on a remote
system. Seems obvious -- it is ssh based, but
This is mostly a test to see if this makes it through to the list.
Something else I tried to
post recently never showed up, and I didn't get back an error message.
Also didn't show in
bash list archives.
Subject line of missing email:
Why difference between interactive+script doing same
On 2022/12/11 20:47, Lawrence Velázquez wrote:
This happens because "declare"/"typeset" creates local variables
within functions. Using -g works around this...
$ Export() { declare -gx "$@"; }
$ Export -r foo=1
$ declare -p foo
declare -rx foo="1"
...but now
This is mostly a 'nit', but I noticed I had
"typeset -xr"
in one of my scripts to mean export+read-only and
was wondering why
"export -r"
was disallowed (err message):
bash: export: -r: invalid option
export: usage: export [-fn] [name[=value] ...] or export -p
This seems to be an
On 2022/12/06 10:57, Chris Elvidge wrote:
Yair, how about using the Python installed in the WSL instance.
---
Oh, I wondered why Python used CRLF, but nothing else did.
What version of python are you using? The Python for WSL,
the python for cygwin, or the python for Windows? If you
On 2022/06/13 15:39, Paul Eggert wrote:
In many Gnu projects, the 'configure' script is the biggest barrier to
building because it takes s long to run. Is there some way that we
could improve its performance without completely reengineering it, by
improving Bash so that it can parallelize
On 2022/03/23 09:49, Chet Ramey wrote:
On 3/23/22 7:56 AM, Robert Elz wrote:
You might not like the terminology, but it is what it is,
and you don't get to arbitrarily redefine it, unless you
change your name to Humpty Dumpty.
Bonus points for the "Through the Looking Glass"
On 2022/03/23 00:25, Ilkka Virta wrote:
The POSIX phraseology is that "null" means the empty string.
POSIX phraseology applies to the POSIX language.
In 'C'
char *s = NULL
is not the same as
char *s="";
They aren't the same at the machine level nor at the language level.
In
On 2022/03/22 14:04, Lawrence Velázquez wrote:
On Tue, Mar 22, 2022, at 4:53 PM, L A Walsh wrote:
On 2022/03/21 03:40, Alex fxmbsw7 Ratchev wrote:
i solve this by shopt -s nullglob
Repeat-By:
Code: x=("/"); for i in "${x[@]%/}"; do echo "i
On 2022/03/22 13:53, L A Walsh wrote:
On 2022/03/21 03:40, Alex fxmbsw7 Ratchev wrote:
i solve this by shopt -s nullglob
Repeat-By:
Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
Result: none
Expected result: i is ''
On 2022/03/21 05:45, Andreas Luik wrote:
Description:
Bash fails to correctly test for parameter to be unset or null when the
parameter is an array reference [*] or [@].
Repeat-By:
myvar[0]=
echo "${myvar[0]:+nonnull}"
-> OK
echo "${myvar[*]:+nonnull}"
nunnull -> not OK, because
On 2022/02/06 09:26, Frank Heckenbach wrote:
On 2022/01/02 17:43, Frank Heckenbach wrote:
Why would you? Aren't you able to assess the severity of a bug
yourself? Silent data corruption is certainly one of the most severe
kind of bugs ...
---
That's debatable, BTW, as I was
On 2022/01/02 17:43, Frank Heckenbach wrote:
Chet Ramey wrote:
After all, we're talking about silent data corruption, and now I
learn the bug is known for almost a year, the fix is known and still
hasn't been released, not even as an official patch.
If you use the number of bug
On 2022/02/03 11:02, Chet Ramey wrote:
On 2/2/22 10:18 PM, Robert Elz wrote:
Date:Wed, 02 Feb 2022 17:18:08 -0800
From:L A Walsh
Message-ID: <61fb2d50.7010...@tlinx.org>
| My posix non-conformance issue has to do with bash not st
On 2022/02/03 07:02, Alex fxmbsw7 Ratchev wrote:
On Thu, Feb 3, 2022, 04:20 Robert Elz <mailto:k...@munnari.oz.au>> wrote:
Date:Wed, 02 Feb 2022 17:18:08 -0800
From: L A Walsh mailto:b...@tlinx.org>>
Message-ID: <61fb2d50
On 2022/02/02 08:50, Chet Ramey wrote:
On 2/2/22 8:25 AM, L A Walsh wrote:
I.e. My bash is posix compliant by default w/r/t aliases:
It's not, and that's how this whole issue got started. You're running
bash-4.4. POSIX requires the following to work:
alias switch=case
echo
On 2022/02/01 07:50, Chet Ramey wrote:
"Historically some shells used simple parenthesis counting to find the
terminating ')' and therefore did not account for aliases. However, such
shells never conformed to POSIX, which has always required recursive
parsing (see XCU 2.3 item 5)."
On 2022/02/02 06:43, Alex fxmbsw7 Ratchev wrote:
i had gdb new version
---
This is about looking at a backtrace of shell functions in shell
gdb may show a backtrace of shell functions, but gdb isn't
a shell debugger, but one for the source code of bash.
If you look at my backtrace function
BTW, thinking about how this problem would arise
On 2022/01/20 22:43, Lawrence Velázquez wrote:
Depends what you consider to be an issue. Personally, I would be
less than pleased if my whole terminal turned red just because I
changed into a directory that happened to have a weird name.
I was trying to find parameters to a function that gave an error, so
I 'turned on' (included my backtracing routine), which showed:
./24bc: line 46: printf: `txt=\nRed,': not a valid identifier
STOPPING execution @ "printf ${_:+-v $_} '\x1b[48;2;%s;%s;%sm' $1 $2 $3"
in "setBgColor()" at ./24bc
On 2022/01/31 20:40, Martijn Dekker wrote:
On the latest code from the devel branch:
GNU bash, versie 5.2.0(35)-alpha (x86_64-apple-darwin18.7.0)
Reproducer script:
shopt -s expand_aliases
alias let='let --'
set -x
let '1 == 1'
: $(let '1 == 1')
Output:
+ let -- '1 == 1'
++ let -- -- '1 ==
On 2022/01/22 12:48, Andreas Kusalananda Kähäri wrote:
The shell even keeps the PS1 variable's value from its inherited
environment
without sanitizing it.
This is a requirement of the unix/posix model that has 'fork'
create a new process that is a new unfiltered, unsanitized copy of
On 2022/01/20 22:20, Lawrence Velázquez wrote:
On Fri, Jan 21, 2022, at 12:22 AM, L A Walsh wrote:
On 2022/01/18 22:31, Alex fxmbsw7 Ratchev wrote
Fix: [sanitizing the prompt].
Sanitizing? What's that?
Especially in a way that won't break existing legal usages
On 2022/01/18 22:31, Alex fxmbsw7 Ratchev wrote
Fix:
Haven't looked deeply into the bash internals but sanitizing the directory
name (along with other user-controlled substitutions in the prompt) should
work.
Sanitizing? What's that?
Especially in a way that won't break existing legal
On 2021/11/12 01:36, Mischa Baars wrote:
Hi All,
All of my makefiles only compile source files and link object files that
are NEW, as in the modification timestamp is newer than OR EQUAL TO the
access timestamp, such that when I include a new source file into a project
or produce a new object
On 2021/12/21 20:07, Greg Wooledge wrote:
On Tue, Dec 21, 2021 at 10:48:07PM -0500, Dale R. Worley wrote:
Lawrence Vel�zquez writes:
Did you mean to say that ${#FOO[*]} causes an error? Because
${FOO[*]} does not, a la $*:
The case that matters for me is the Bash that
On 2021/10/30 09:07, Robert Elz wrote:
oguzismailuy...@gmail.com said:
| `break' is not a keyword in the shell, but a special command.
That's true. However, 99%**1 of script writers don't see
it that way,g they believe it is just like "if" or
"while" or "done" or "return".
That's
On 2021/10/29 12:33, Greg Wooledge wrote:
On Fri, Oct 29, 2021 at 11:59:02AM -0700, L A Walsh wrote:
How much lameness Chet has introduced into bash to accommodate
the wrong users.
This is quite unfair.
Huh? It's true--look at how functions have to be stored in
the environment
On 2021/10/29 05:01, Greg Wooledge wrote:
On Fri, Oct 29, 2021 at 12:48:57PM +0300, Ilkka Virta wrote:
Not that I'm sure the upper one is still safe against every input. I think
issues with associative array keys have been
discussed on the list before.
Sadly, yes. Bash is the
On 2021/10/05 16:25, Tom Coleman wrote
Repeat-By:
Below is a sample script to replicate the bug in LINENO.
---
1st prob: scrip doesn't work as is.
/tmp/lnno
/tmp/lnno: line 23: syntax error near unexpected token `done'
/tmp/lnno: line 23: ` done'
added the line numbers
On 2021/09/05 20:54, Lawrence Velázquez wrote:
On Sun, Sep 5, 2021, at 11:11 PM, Dale R. Worley wrote:
L A Walsh writes:
I know how -h can detect a symlink, but I was wondering, is
there a way for bash to know where the symlink points (without
using an external program)?
My
I know how -h can detect a symlink, but I was wondering, is
there a way for bash to know where the symlink points (without
using an external program)?
Like if I'm running a script and check if something
is a symlink to a dir that isn't there, is there a way
to read the value of a symlink like a
On 2021/09/01 02:36, David Collier wrote:
Version:
GNU bash, version 5.0.3(1)-release (arm-unknown-linux-gnueabihf)
Raspberry Pi using Raspbian.
Installed from repo?
LINENO goes backwards when run sync
LINENO isn't the number of lines executed, but is the
linenumber in the source
On 2021/08/24 05:06, Greg Wooledge wrote:
Looks like the efficiency of "read -ra" vs. a shell loop just about makes
up for the system calls used for the here string (f6 and f7 are almost
tied in overall speed, with f6 just a *tiny* bit faster). Good to know.
If you set your
On 2021/08/23 12:10, Greg Wooledge wrote:
On Mon, Aug 23, 2021 at 11:36:52AM -0700, L A Walsh wrote:
Starting with a number N, is there
an easy way to print its digits into an array?
"Easy"? Or "efficient"? Your subject header says one, but your body
says the
Starting with a number N, is there
an easy way to print its digits into an array?
I came up with a few ways, but thought this
would be nice (with '\1' or '$1' being what was matched
in the 1st part), this could be statement:
arr=(${N//[0-9]/\1 })
or
arr=(${N//[0-9]/$1 })
Instead of using loops
On 2021/08/22 19:14, Koichi Murase wrote:
I'd guess Ilkka has asked the use case for this particular output
format, i.e., the quoted fields inside a single word. If the purpose
is organizing the data, I would naturally expect the result in the
following more useful format in separate words
On 2021/08/19 02:15, Ilkka Virta wrote:
$ declare -A A=([foo bar]="123 456" [adsf]="456 789")
$ printf "<%s>\n" "${A[@]@K}"
Interesting. I wonder, what's the intended use-case for this?
---
Does it matter?: Organizing data.
In this case, the data may be organized by pairs.
If you have a
On 2021/08/14 17:05, Kerin Millar wrote:
On Sat, 14 Aug 2021 15:59:38 -0700
George Nachman wrote:
This does not constitute a valid test case for two reasons. Firstly,
aliases have no effect in scripts unless the expand_aliases shell
option is set.
1) I frequently use for loops
On 2021/08/17 04:02, Osipov, Michael (LDA IT PLM) wrote:
Folks,
this is basically the same issue as I reported in readline:
https://lists.gnu.org/archive/html/bug-readline/2021-08/msg0.html
The bad hunk seems not to be POSIX shell compliant.
I think your eyes are fooling you. I
Not entirely sure how, but have been running 5.1.8(3)-release which seems
fine...up until I wanted to single step a script...
bashdb ...and saw
/usr/share/bashdb/command/set_sub/dollar0.sh: line 23: enable: dynamic
loading not available
(/tmp/rearrange_files.sh:4):
4: shopt -s expand_aliases
On 2021/06/29 19:11, Eli Schwartz wrote:
This is a ridiculous argument and you know it. You, personally, are
writing code which does not get used in security contexts, which is your
right. This in no way means that refusing to quote variables which
"cannot be word-split" stops *any* security
On 2021/06/29 16:51, Greg Wooledge wrote:
On Tue, Jun 29, 2021 at 04:29:05PM -0700, L A Walsh wrote:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
Which is detected as "illegal input" and disallowed. If you don't enable
so
On 2021/06/29 15:49, Greg Wooledge wrote:
On Tue, Jun 29, 2021 at 02:58:28PM -0700, L A Walsh wrote:
njobs() { printf ${1:+-v $1} "%s\n" "$(jobs |wc -l)"; }
Using that with your input:
njobs 'x[0$(date >&2)]'
bash: printf: `x[0$(date': not a valid identifier
On 2021/06/29 14:02, Greg Wooledge wrote:
declare, printf -v, local -n, eval -- they're mostly equivalent. Some
of them may prevent *some* possible code injections, but none of them
prevent *all* possible code injections.
unicorn:~$ njobs2() { printf -v "$1" %s 42; }
unicorn:~$ njobs2
On 2021/06/29 13:35, Greg Wooledge wrote:
unicorn:~$ njobs() { local _n=$(jobs | wc -l); eval "$1=\$_n"; }
---
ARG...I thought about that and rejected it because I
thought the "jobs|wc-l" would be in a sub-shell and not pickup
the background jobs! Double arg, this works as well:
sjobs() {
On 2021/06/29 13:35, Eli Schwartz wrote:
Well, if you don't think this is a bug in bash, but something you need
help figuring out, maybe you'd prefer to use the "help-bash" list?
Actually
-
The original message was received at Tue, 29 Jun 2021 13:06:34 -0700
The
I hope a basic question isn't too offtopic.
Say I have some number of jobs running:
jobs|wc -l
3
---
in a function (have tried shopt -s/-u lastpipe; neither way worked)
njobs() {
jobs |wc -l
}
njobs
3
Would like to pass a varname to njobs to store the answer in, like:
njobs() {
jobs|wc -l
On 2021/06/06 04:48, Léa Gris wrote:
Le 06/06/2021 à 11:33, Ilkka Virta écrivait :
In fact, that generic 'they' is so common and accepted, that you just
used
it yourself
in the part I quoted above.
Either you're acting in bad faith, or you're so confused by your
gender-neutral delusion that
On 2021/06/06 07:19, Alain D D Williams wrote:
The important thing is that there is no intention to oppress/denigrate/...
But it does _suggest_ that the default user is a male.
or, speaking about historical use, that the default user was
male. The problem comes when someone reads gendered
On 2021/06/05 08:35, Oğuz wrote:
5 Haziran 2021 Cumartesi tarihinde Vipul Kumar <
kumar+bug-b...@onenetbeyond.org> yazdı:
Hi,
Isn't it a good idea to prefer non-gender specific pronoun (like "their"
instead of "his") at following places in the reference manual?
No it's not.
On 2021/04/26 17:16, Chet Ramey wrote:
On 4/26/21 7:19 PM, L A Walsh wrote:
I'm not clear if termcap lib has this or not, when the curses
library is in use, it supports the idea of reading and setting
the term [tab]size.
Can't you do this with `stty size' already?
Setting size: sometimes
I'm not clear if termcap lib has this or not, when the curses
library is in use, it supports the idea of reading and setting
the term size.
Users can set this with the 'tabs' program included in the
curses package. Besides supporting X/Open standards for
tabs for some specific languages, it
On 2021/04/06 08:52, Greg Wooledge wrote:
In that case, I have no qualms about proposing that unset 'a[@]' and
unset 'a[*]' be changed to remove only the array element whose key is
'@' or '*', respectively, and screw backward compatibility. The current
behavior is pointless and is nothing but a
On 2021/03/30 13:54, Lawrence Velázquez wrote:
Further reading:
https://mywiki.wooledge.org/BashPitfalls#echo_.22Hello_World.21.22
---
I find that disabling history expansion via '!' at bash-build
time is the most ideal solution, since someone preferring 'csh' would
likely still be using
On 2021/04/06 00:23, Oğuz wrote:
5 Nisan 2021 Pazartesi tarihinde L A Walsh <mailto:b...@tlinx.org>> yazdı:
On 2021/04/03 00:41, Oğuz wrote:
but I
don't think it's useful at all because the number of pending
traps keeps
piling up, and there
On 2021/04/03 00:41, Oğuz wrote:
but I
don't think it's useful at all because the number of pending traps keeps
piling up, and there is no way to reset that number. If there is no real
use case for recursive SIGCHLD traps (which I can't think of any), I think
this should change; no SIGCHLD trap
On 2021/03/29 20:04, Greg Wooledge wrote:
On Mon, Mar 29, 2021 at 07:25:53PM -0700, L A Walsh wrote:
I have both /etc/profile and /etc/bashrc call my configuration
scripts. Are there common paths that don't call one of those?
A vanilla bash compiled from GNU sources
On 2021/03/29 14:39, Greg Wooledge wrote:
On Mon, Mar 29, 2021 at 01:49:41PM -0700, L A Walsh wrote:
Or, what do you mean by 'default'? Is it sufficient
to set it in the system /etc/profile so it is the default
for all users when logging in?
Sadly, that won't work. There are plenty
On 2021/03/28 11:02, Eric Cook wrote:
On 3/28/21 7:02 AM, Oğuz wrote:
As it should be. `[bar]' doesn't qualify as an assignment without an equals
sign, the shell thinks you're mixing two forms of associative array assignment
there.
In the new form, that a key is listed inside a compound
On 2021/03/29 04:04, ილია ჩაჩანიძე wrote:
How can I set default PS1 variable from source code?
---
What do you mean "from source code?"
E.g I want it to display:
My-linux-distro $
And not:
Bash-5.1 $
---
Does the procedure documented in the bash man page not work?
Or, what do you
On 2021/03/23 21:41, Lawrence Velázquez wrote:
On Mar 23, 2021, at 11:43 PM, Eli Schwartz wrote:
It's not clear to me, how you expect this to differ from the existing
behavior of "$@" or "${arr[@]}" which already expands to
rather than an actual "" parameter.
The original message
Too often I end up having to write something like
if (($#)); then "$@"
else # = function or executable call
fi
It would be nice to have a expansion that preserves arg boundaries
but that expands to nothing when there are 0 parameters
(because whatever gets called still sees "" as a
On 2021/03/15 17:12, Chet Ramey wrote:
I'm kicking around a change
This means that, given the following script,
declare -A a
key='$(echo foo)'
a[$key]=1
a['$key']=2
a["foo"]=3
What do folks think?
---
Looks like a flexible way to deal with some of the side effects
of the
On 2021/02/28 14:13, Chet Ramey wrote:
On 2/27/21 6:14 AM, Alex fxmbsw7 Ratchev wrote:
These code fragments have nothing to do with each other. Why not include
a self-contained example that includes relevant `stuff' in what you're
passing to `unset'?
cuz he's trollin us?
On 2021/02/23 14:10, Chet Ramey wrote:
On 2/22/21 10:09 PM, L A Walsh wrote:
export _home_prefix=${HOME%/*}/
I can't reproduce it, though I'm sure this is the line where it
crashes for you. What is HOME set to?
HOME=/home/law
so _home_prefix will be '/home'
You are thinking
(Doi!) Forgot it was executing initial rc scripts.
Turned on -x since last statement seems pretty mundane.
Also 6 statements after where it claimed it crashed, is
a custom function for printing pwd for the prompt.
I've tried with different compile ops (optim vs. dbg).
with builtin readline and
I'm trying to build bash 5.1.3, and at first
I tried w/bash-malloc, but got:
/bash-5.1> ./bash
malloc: subst.c:4751: assertion botched
free: called with unallocated block argument
Aborting...Aborted (core dumped)
---
Another prob which seems a bit odd -- more than once, on the
first time after
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 checkhash
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/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
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
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',
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
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 allows it to be sure
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
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
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
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,
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
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
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
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
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 often did unwanted things, but I never
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
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 ((... ==
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
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
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:
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
1 - 100 of 349 matches
Mail list logo
