On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports for
the GNU Bourne Again SHell wrote:
> I was expecting to see:
> 12345
> #!./bash -xv
> x="1 2 3 4 5"
> for z in "$x"
> do
> echo "$z"
> done
> exit 0
Not a bug. You've created a string of length 9 chara
On Sat, Oct 05, 2019 at 02:41:38PM +0530, Kartikey Tewari wrote:
> Description:
> I am using Microsoft Windows-10 -wsl ubuntu.
> when dubugging c++ codes having extension .cpp via gdb debugger, I observe
> that TUI does not get rendered properly.
GDB is not part of bash. You need to submit your b
On Mon, Oct 07, 2019 at 08:05:12PM +0700, pepa65 wrote:
> > On Sat, Oct 05, 2019 at 06:48:35PM +, George R Goffe via Bug reports
> > for the GNU Bourne Again SHell wrote:
> >> I was expecting to see:
> >> 12345
> >
> > If you want to create a *list* and iterate over that list, one element
> >
On Mon, Oct 07, 2019 at 04:23:44PM +0200, Andreas Schwab wrote:
> On Okt 07 2019, Greg Wooledge wrote:
>
> > x=(1 2 3 4 5 -n '/*' 'hello world')
> > for z in "${x[@]}"; do
> > printf %s "$z"
> > done
> > echo
>
&g
On Mon, Oct 14, 2019 at 12:37:34PM +0200, Mischa Baars wrote:
>
> I believe you're missing the point. You were probably distracted by me
> brabbling about whitespaces.
1. The questioner's first description of the problem/question will
be misleading.
1.1 The questioner's second description
On Mon, Oct 14, 2019 at 10:39:41AM +, Daniel Hannon wrote:
> the use of the "…" character results in the ability to delete the bash prompt
> string using backspace
I can't reproduce this.
wooledg:~$ bash
wooledg:~$ PS1='…\h:\w\$ '
…wooledg:~$ echo "$BASH_VERSION"
5.0.3(1)-release
…wooledg:~$
en_IE.UTF-8"
> LC_PAPER="en_IE.UTF-8"
> LC_NAME="en_IE.UTF-8"
> LC_ADDRESS="en_IE.UTF-8"
> LC_TELEPHONE="en_IE.UTF-8"
> LC_MEASUREMENT="en_IE.UTF-8"
> LC_IDENTIFICATION="en_IE.UTF-8"
> LC_ALL=
>
> enclosed is a video
On Mon, Oct 21, 2019 at 09:19:48AM +, "Göbbert, Jens Henrik" wrote:
> Description:
> "bash --rcfile --login test.sh" will run test.sh but "bash --login
> --rcfile test.sh" will not, even though this would be expected from the
> help/man pages.
--rcfile takes an argument. It has to b
On Thu, Oct 24, 2019 at 09:01:07AM +0200, francis.montag...@inria.fr wrote:
> When logged on a machine with ssh, executing a simple command CMD1
> that spawn a "/bin/bash -c some other command" do not source
> ~/.bashrc: normal behaviour.
>
> When executing "CMD1 | CMD2", the ~/.bashrc is
On Mon, Nov 25, 2019 at 02:08:04PM +0200, IFo Hancroft wrote:
> I have the following feature request:
>
> Output/send \033]7;file:///the/current/dir\033\\ on directory change.
cd() {
builtin cd "$@" &&
printf '\e]7;file://%s\a' "$PWD"
}
pushd() {
builtin pushd "$@" &&
printf '\e]
On Mon, Nov 25, 2019 at 04:33:13PM +0200, IFo Hancroft wrote:
> > You can do it yourself, by putting the functions I just gave you into
> > your ~/.bashrc file. This kind of change doesn't belong in the shell
> > itself, because it will *not* be a "clean solution" for everybody.
> >
> I know I ca
On Mon, Nov 25, 2019 at 01:43:41PM -0800, Peter Benjamin wrote:
> Description:
> 'in' is a builtin command and is not listed in the man page as such.
It's actually a keyword. It's part of the "for" and "case" syntax.
wooledg:~$ type in
in is a shell keyword
for NAME in WORDS; do ...; done
cas
On Tue, Nov 26, 2019 at 07:35:09AM -0600, Dennis Williamson wrote:
> On Tue, Nov 26, 2019, 5:46 AM Алексей Шилин wrote:
> > And they *are* enclosed: PS1='\[\e]0;\u@\h: \w\a\]${debian_chroot...
>
> You have printable characters enclosed. For example, \u. _Each_ sequence of
> unprintable characters
On Wed, Nov 27, 2019 at 11:02:49AM -0500, Chet Ramey wrote:
> On 11/25/19 10:05 AM, Алексей Шилин wrote:
> > I'm using the following PS1 prompt (Debian's default for normal users):
> >
> > \[\e]0;\u@\h:
> > \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\
> > ]:\[\033[01;34m
On Sun, Dec 01, 2019 at 03:20:54PM +, George R Goffe via Bug reports for
the GNU Bourne Again SHell wrote:
> mkdir ()
> {
> dirs="$@";
> for dir in $dirs;
> do
> /bin/mkdir -p "$dir";
> done
> }
This function is severely flawed. I believe this is what you wanted:
mkdir() {
command mkdir
On Mon, Dec 02, 2019 at 09:51:12PM +0700, pepa65 wrote:
> On 12/2/19 9:38 PM, Andreas Kusalananda Kähäri wrote:> for dirpath do
> > command mkdir -p "$dirpath" || return
> > done
> It is very sad that the 'do' is not optional (non-backwards compatibility
> breaking feature reques
On Mon, Dec 02, 2019 at 10:06:36AM -0500, Eli Schwartz wrote:
> But I think I'll still use them despite being not strictly needed, or
> I'll just confuse myself once I do need them. :p I've used them for too
> long by now, anyway.
Yeah, same here. I prefer it with the semicolon.
On Mon, Dec 02, 2019 at 01:41:11PM -0500, Chet Ramey wrote:
> On 12/1/19 10:20 AM, George R Goffe via Bug reports for the GNU Bourne
> Again SHell wrote:
> > mkdir ()
> > {
> > dirs="$@";
> > for dir in $dirs;
> > do
> > /bin/mkdir -p "$dir";
> > done
> > }
> >
> >
> >
> > make[1]: Leaving dire
On Thu, Dec 12, 2019 at 11:43:58AM -0800, L A Walsh wrote:
> > read -r -a a< <(printf "%q " {Z..a})
> > my -p a
> declare -a a=([0]="Z" [1]="\\[" [2]="''" [3]="\\]" [4]="\\^" [5]="_"
> [6]="\\\`" [7]="a")
Nice try. I guess the takeaway from this thread is: "You cannot mix
capital and lowercase
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 larger issue to be addressed first. The man page says,
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 expands
On Mon, Dec 16, 2019 at 04:37:28PM +0100, Christian Dürr wrote:
> Repeat-By:
> Paste `https://こんにち` into bash and add whitespace before it until it is
> in the next line. Then start deleting that whitespace until it is on the
> previous line again. It should crash as soon as only `https
On Wed, Dec 18, 2019 at 11:15:46AM -0800, L A Walsh wrote:
> On 2019/12/16 08:39, Greg Wooledge wrote:
> > The problem is, it is *not possible* to extract the set of characters
> > out of an arbitrary locale. The locale interfaces simply are not built
> > to allow it.
>
On Wed, Dec 18, 2019 at 03:08:20PM -0500, Eli Schwartz wrote:
> So all bash needs to do to print {Z..a} is to take Z == ASCII decimal 90
> and a == ASCII decimal 97, then enumerate the numbers 90-97 and
> translate them into ascii. No locale awareness is needed, no heuristics,
> no invocation of th
On Fri, Dec 20, 2019 at 10:40:26AM -0400, Bize Ma wrote:
> I am not the one making those comments. I don't have enough C expertise
> to neither confirm or deny them. But that also makes me unable to answer to
> the
> author of the comments in the proper way. I intended to receive something to
> cor
On Fri, Dec 20, 2019 at 04:35:05PM -0800, L A Walsh wrote:
> 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
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 give an example, with a starting character and an ending
char
On Fri, Jan 17, 2020 at 05:09:08PM -0600, Andy Goth wrote:
> On 2020-01-17 16:47, Andy Goth wrote:
> > I spotted a tiny typo in the documentation for bash-5.0.11
>
> Oh yes, there's also a file called bash.0 that needs to be kept in sync with
> bash.1. It's probably generated by a script to make
On Tue, Jan 21, 2020 at 04:14:52PM -0500, Chet Ramey wrote:
> On 1/21/20 4:13 PM, William Theisen wrote:
> > I've just tested this, it's a little awkward but does actually work. Thanks
> > for the suggestion I'll play around with making it a little more
> > convenient to use. Thanks for your time.
On Mon, Jan 27, 2020 at 09:03:22PM -0500, Roger wrote:
> I've always had a problem with Bash script (eg. for/while) loops creating
> havoc
> upon a ctrl-c keypress.
What's *in* the loop? It matters.
Consider the following two scripts:
==
#!/bin/bash
while true;
On Tue, Jan 28, 2020 at 03:49:32PM -0500, Roger wrote:
> As I slept on this, I realized the likeliness some programs are also trapping
> CTRL-C as you just explained.
>
> The programs I'm using within a loop were ffmpeg && mv (rename) after
> verifying
> ffmpeg created a file >0 bytes.
I'm not
On Wed, Jan 29, 2020 at 12:57:41PM +0700, Robert Elz wrote:
> Incidentally, since sh (all implementations, including bash) has a global
> variable namespace, the biggest source of variable name conflicts is
> usually with other sh scripts (functions, startup files,
> environment variables...) that
On Wed, Jan 29, 2020 at 01:05:32PM +0700, Robert Elz wrote:
> and (with all respect to Gred) please avoid archaic uses, and use the
> commands as they're currently specified, while "trap - INT" and "trap INT"
> do the same thing, the former is the standard way, similarly for
> "kill -INT ..." and "
On Wed, Jan 29, 2020 at 10:19:55AM -0500, Clint Hepner wrote:
> bash-5.0$ IFS== read -r n v <<< "name=var="
> bash-5.0$ echo "$v"
> var
https://mywiki.wooledge.org/BashPitfalls#pf47
On Thu, Jan 30, 2020 at 01:03:31AM +0700, Robert Elz wrote:
> It actually doesn't, or not generally - it allows the function to avoid
> namespace collisions with random globals (or other locals) that might exist
> up the call stack, but doesn't prevent functions that are called from
> trampling all
On Wed, Jan 29, 2020 at 03:19:07PM -0500, Roger wrote:
> >sigint_handler() {
> >trap - INT
> >kill -INT $$
> >}
> >trap sigint_handler INT
>
> One thing to note here, I tried inserting the "trap sigint_handler INT" prior
> to the loop/for/while statement (or outside of the loop) and the t
On Thu, Jan 30, 2020 at 11:37:26AM +0800, konsolebox wrote:
> You can still use all caps on global variables just mind the internal
> variables.
Easier said than done. How many times have you had to diagnose
someone's failing script, and it turned out the reason it was failing
was because they us
On Fri, Feb 07, 2020 at 05:11:43PM +1000, Magnon Damant wrote:
> I noticed a bug where when I open a Time Machine Backup folder (called .HFS+
> Private Directory Data'$'\r) the terminal cursor position gets messed up.
"Open" is a bit ambiguous here
> prompt [@
> ]$ gets messed up
>
> I guess
On Thu, Feb 20, 2020 at 01:46:25AM +0100, Arfrever Frehtes Taifersar Arahesis
wrote:
> Is there any way for using ${!variable} combined with
> ${variable@operator}
No.
On Thu, Feb 20, 2020 at 04:05:01PM +0100, Ulrich Mueller wrote:
> > On Thu, 20 Feb 2020, pepa65 wrote:
>
> > On 20/02/2020 19.48, Ulrich Mueller wrote:
> >> Still, I think it's sad that there isn't a command that can test for
> >> assigned vs void variable, without the need for parsing of decl
On Wed, Feb 26, 2020 at 05:39:22PM +0200, Ricky Tigg wrote:
> Tested on *Gnome*; Component: bash.x86_64 5.0.11
>
> Used Shell;
> $ echo $SHELL
> /bin/bash
>
> Following command opens the queried graphical terminal emulator;
> $ echo q | gnome-terminal
>
> Result in opened terminal:
> [yk@localho
On Wed, Feb 26, 2020 at 11:59:09AM -0500, Eli Schwartz wrote:
> On 2/26/20 10:48 AM, Greg Wooledge wrote:
> > If you're trying to pre-populate the input buffer of a shell in a newly
> > launched terminal emulator, you're about to go down some very deep
> > rabbit hol
On Thu, Feb 27, 2020 at 09:39:35AM +0200, Ricky Tigg wrote:
> Hey. Goal: scheduling tasks along with visual output in terminal. I
> concieved it could be achieved under Linux. I had defined a use-case for
> that purpose..
>
> $ at -q c now + 1 minute
> warning: commands will be executed using /bin
On Mon, Mar 02, 2020 at 11:54:24AM -0800, Keith Thompson wrote:
> /bin/echo hello \
> > BASH_BUG_TEST_$((i++))_$word
The redirection happens in the subshell that was created to run the
external command.
On Wed, Mar 04, 2020 at 03:43:26PM -0500, Chet Ramey wrote:
> On 3/4/20 2:38 PM, Chris Down wrote:
> > --- a/jobs.c
> > +++ b/jobs.c
> > @@ -4584,6 +4584,7 @@ initialize_job_signals ()
> > if (interactive)
> > {
> > set_signal_handler (SIGINT, sigint_sighandler);
> > + set_signa
On Tue, Mar 10, 2020 at 06:37:24PM +0100, Phi Debian wrote:
> In a nutshell to implement a function autoloading I want to plug into
> command_not_found_handle(), but I need command_not_found_handle()be
> evaluated in the shell context, not in a subshell.
You can't. Bash has already forked the sub
On Tue, Mar 10, 2020 at 08:57:26PM +0100, Phi Debian wrote:
> Secondly, if yuio insist on going on the subshell path, then $$ and $PPID
> ought to be setup appropriately, here ther are plain bogus.
wooledg:~$ command_not_found_handle() { echo "\$\$=$$ BASHPID=$BASHPID"; }
wooledg:~$ echo "\$\$=$$
On Wed, Mar 11, 2020 at 07:29:38AM -0400, Joseph A. Russo wrote:
> # the following two lines work
> [ 5 < 10 ] && echo true || echo false
> [ 5 > 10 ] && echo true || echo false
You've misunderstood the syntax here. The < sign introduces a
redirection of standard input, from a file named
On Mon, Mar 16, 2020 at 09:47:44AM -0400, Chet Ramey wrote:
> On 3/15/20 7:41 AM, Šimon Let wrote:
> > Hi All,
> >
> > I'm using PROMPT_COMMAND and DEBUG trap to emulate "PRE" and "POST" hooks
> > in bash. I have run into the issue where the DEBUG trap gets triggered when
> > any custom readline w
On Mon, Mar 30, 2020 at 04:24:07AM -0400, Jeffrey Walton wrote:
> I'm testing some software from Master. My testing machines sometimes
> lack the distro tools like makeinfo. It results in things like this:
>
> ./bootstrap: 255: makeinfo: not found
> ./bootstrap: Error: 'makeinfo' not found
On Wed, Apr 01, 2020 at 04:54:42PM +, Krystian Wojtas via Bug reports for
the GNU Bourne Again SHell wrote:
> Script has set errexit flag. It runs function. Function declares
> local variable and set it to output of run subcommand. Subcommand fails.
> Script does not care and continu
On Mon, Apr 06, 2020 at 04:33:15PM +0200, f...@florentbordignon.fr wrote:
> Hello,
>
> The following assertion succeeds when it should not :
> set -e
> ! true
> echo Hello # prints Hello but should not
-e Exit immediately if a pipeline (which may consist of a
On Wed, Apr 08, 2020 at 04:46:19PM -0700, Eduardo Bustamante wrote:
> On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte
> wrote:
> (...)
> > But, as far as I understand, a non-interactive bash doesn't read
> > ~/.bashrc at all - so shouldn't we just omit them?
>
> There are exceptions. One of them b
On Thu, Apr 09, 2020 at 09:48:37AM -0400, Chet Ramey wrote:
> On 4/8/20 7:46 PM, Eduardo Bustamante wrote:
> > On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte
> > wrote:
> > (...)
> >> But, as far as I understand, a non-interactive bash doesn't read
> >> ~/.bashrc at all - so shouldn't we just omit
d array indices, and the numeric parts of
the ${variable:start:length} expansion. And possibly more.
unicorn:~$ x='a[$(id >&2)0]' a=7
unicorn:~$ [[ "$x" -eq 42 ]]
uid=1000(greg) gid=1000(greg)
groups=1000(greg),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video
On Fri, Apr 17, 2020 at 03:22:16PM +0100, Sam Liddicott wrote:
> printf %q with a truncating size will emit partially escaped
> sequence thus losing the safety and composability that %q
> is intended to provide.
So... don't do that.
On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote:
> On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for
> the GNU Bourne Again SHell wrote:
> >
> > I've noticed that if I trap SIGINT in a bash script, the behavior when
> > encountering C-c depends on whether an
On Sat, Apr 18, 2020 at 05:37:52AM +0700, Robert Elz wrote:
> The end result is as Greg said, "Don't do that", if precisions are
> needed with %q do something like
>
> printf 'echo %q%q\n' "$(printf %.2s "a'b")" ';ls'
the previous bug (which
occurs when the multi-line command was read from $HISTFILE) and the
present one (which occurs when it was entered into the current shell
session directly).
Thanks,
Greg
From 495f46ec7e1f97e35d24515ccad9b2bd1f8fa60c Mon Sep 17 00:00:00 2001
Message-Id: <495f46ec7e1f
On Mon, Apr 20, 2020 at 06:48:44PM +0900, Koichi Murase wrote:
> Also, I am sorry that I disturbed your plan for contributing to Bash.
> I actually initially doubted that the insertion with the current
> implementation is O(N), so I created the test first and then found
> that it is an easy fix rat
On Mon, Apr 20, 2020 at 05:12:28PM -0400, George Jones wrote:
> No real opinion on syntax.
>
> Using something existing:
>
> declare -A foo[SIZE]
>
> seems sensible, especially if there was no semantic meaning (I'm not a fan
> of syntax without semantics clutter).
That's pretty C-like,
On Mon, Apr 20, 2020 at 10:25:30PM -0400, Dale R. Worley wrote:
> Is this the proper place to make suggestions for improving Bash?
Yes. It should also be noted that there is no public bug tracker,
other than the archives of this mailing list. So, it can be difficult
to tell which suggestions hav
On Tue, Apr 21, 2020 at 08:38:41PM -0400, Dale R. Worley wrote:
> The "unbuffered pipe" symbol ">|>" causes Bash to set in the
> environment of the "grep" process a variable "STDOUT_UNBUFFERED" with
> a value that contains the dev and ino values for the pipe which the
> "grep" process sees as fd 1.
On Mon, Apr 27, 2020 at 10:40:26AM -0400, Eva Farrell wrote:
> I am trying to a password for root, because I do not have one I have over
> 30 updates I need to install but it won't let me. When I open Terminal it
> says
> eva@E4620~$
>
> and I try sudo apt-get update it ask for my password however
On Tue, Apr 28, 2020 at 08:14:28PM +0200, andrej--- via Bug reports for the GNU
Bourne Again SHell wrote:
> f() { local x=a; }
> declare -r x
> f # bash: local: x: readonly variable
>
> This^^^ should not fail; it hinders reusability of shell functions and makes
> them context-de
On Thu, Apr 30, 2020 at 10:43:53PM -0400, Dale R. Worley wrote:
> This is a common issue in language design. The Perl language originally
> only had "local" declarations that behaved the same way as bash local
> declarations. But the above behavior got to be so much of a problem for
> large progr
e same confusion for others.
Thanks, regards,
Greg
---
doc/bash.1 | 2 ++
1 file changed, 2 insertions(+)
diff --git doc/bash.1 doc/bash.1
index 151c14cb5..7ba22b614 100644
--- doc/bash.1
+++ doc/bash.1
@@ -5492,6 +5492,8 @@ The name of this file is taken from the value of the
.B INPUTRC
On Fri, May 08, 2020 at 02:26:34PM -0700, Paul Kelaita wrote:
> Only seeing this on Alpine BusyBox (iSH) on iOS 13.x with either 5.0.11 or
> 5.0.17
Busybox is a shell, in addition to being other tools. Perhaps you're
not even in bash at all?
What does "ps -p $$" say? How about "set | grep BASH
On Tue, May 19, 2020 at 06:10:30PM +0530, Inian Vasanth wrote:
> The behavior of arithmetic context operator $((..)) inside [[..]] is not so
> well defined.
It's simply a substitution. The $(( )) is evaluated, and the result
is placed into the [[ ]] command as a word.
> The downside is the opera
On Thu, May 28, 2020 at 08:02:18AM +0100, Laurent Picquet wrote:
> function aFunction {
> local aVar="$(somethingThatFails)" || { echo "is expected to go there";
> return 1; }
> }
"local" is a command with its own separate exit status. It masks
the exit status of the command substitution.
Ru
On Sun, May 31, 2020 at 11:57:03PM -0400, John Passaro wrote:
> I think the underlying question here is not exactly "how do I gather this
> from the docs" as much as it is "how was I supposed to know about this and
> act on it before I had to debug it?"
I don't believe the bash documentation is th
On Tue, Jun 02, 2020 at 09:44:45PM -0400, Dale R. Worley wrote:
> Naively, I expect that
> FOO="$( command2 )"
> command1 "$FOO"
>
> has the same effect as
>
> command1 "$( command2 )"
>
> Has anyone pushed the boundaries of this and can tell me whether there
> are gotchas?
The mai
On Mon, Jun 01, 2020 at 05:28:20PM +0700, Robert Elz wrote:
> in this case:
>
> | You're merely the latest person to discover that this applies to you:
> | http://mywiki.wooledge.org/BashFAQ/105
>
> doesn't really apply - the cases reported are simply bugs in bash,
> a shell implementing -e c
On Mon, Jun 08, 2020 at 02:28:05AM +0100, Dan Shearer wrote:
> Some g commands are implemented, but incorrectly. Examples:
> * g0 is equivalent to 0, rather than 'beginning of screen line when wrapped'
> * g$ is equivalent to $, rather than 'end of screen line when wrapped'
>
> Other g commands ar
On Wed, Jun 17, 2020 at 09:30:25PM +, bry...@giraffe-data.com wrote:
> With TERM environment variable set to an undefined terminal type, Bash
> echoes a backspace as a space; I expect it to echo as a backspace (ctl-h).
> It edits the line properly; it just isn't displayed correctly.
>
Also, of import in any terminal question is the content of your
prompt (PS1 variable).
See https://mywiki.wooledge.org/BashFAQ/053
On Thu, Jun 18, 2020 at 08:53:57PM +, Bryan Henderson wrote:
> I see this with an X.org xterm under Linux and a Linux virtual console, both
> through SSH (Openssh), and Putty in Windows, via Putty's SSH.
>
> To simplify things, I set my erase key to "q" (stty erase q). ctl-V q
> confirms term
On Tue, Jun 23, 2020 at 12:21:24PM -0700, L A Walsh wrote:
> set output
> output=""printf ${1:+-v $1} "%s:%s" 23 myproc
> -Bash: printf: ` output': not a valid identifier
Your command is simply wrong. You've got two double-quotes in a row,
which simply cancel each other out, as they contain only
On Tue, Jun 23, 2020 at 12:33:23PM -0700, L A Walsh wrote:
> 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.
First, stop top-quoting.
Second, if you know that gmail is horrible and is going to mang
On Wed, Jun 24, 2020 at 01:09:48PM +0800, Humanities Clinic wrote:
> version.c:27:10: fatal error: 'version.h' file not found
> jobs.c:72:10: fatal error: 'builtins/builtext.h' file not found
> I double-checked the original folder in
> http://ftp.gnu.org/gnu/bash/bash-3.2.57.tar.gz. It's true the
On Thu, Jun 25, 2020 at 10:46:01AM -0700, L A Walsh wrote:
> But that wouldn't follow the email response instructions of posting your
> response above the previous email
STOP DOING THAT!
That's the OPPOSITE of what you're supposed to do on Unix-based mailing
lists, Usenet, and other sensible plac
On Sun, Jun 28, 2020 at 03:49:45PM +0200, felix wrote:
> Bash Versions: 3.2.57(1)-release, 5.0.3(1)-release, 5.1.0(1)-alpha
>
> In order to reduce forks and make some tasks a lot quicker, I run
> forked filters as background tasks, with dedicated I/O fd.
As Pierre already suggested, you appear to
On Mon, Jun 29, 2020 at 08:24:01PM +, Krongard, William T. (BLM) wrote:
> Description:
> execution of "bash" from shell window gets a division by zero message
> # bash
> bash: (1-0/roothome1): division by 0 (error token is "roothome1)")
> bash: (1-0/roothome1): division by 0 (error toke
On Wed, Jul 01, 2020 at 07:21:04PM +0200, felix wrote:
> Again, I use this for not only with `date` and `bc`, but with `mysql`, `ftp`
> or even `ssh` too.
You're like the poster child for Expect.
On Thu, Jul 02, 2020 at 12:46:33AM +0700, Robert Elz wrote:
> POSIX says:
>
> If command is specified, exec shall not return to the shell;
>
> but in bash...
>
> bash
> jinx$ echo $$
> 23361
> jinx$ exec :
> bash: exec: :: not found
> jinx$ echo $$
> 23361
You're in an interactive shell.
On Sat, Jul 04, 2020 at 01:42:00PM -0500, bug-b...@trodman.com wrote:
> On Fri 7/3/20 14:03 -0400 =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= wrote:
> >What's wrong with `foo | tee /dev/stderr | bar`?
>
> but your soln is simplier. I assume /dev/stderr is on non linux UNIX
> also.
It is *not*. It is no
On Fri, Jul 03, 2020 at 07:00:54PM +0100, Chris Elvidge wrote:
> I've used 'return $((!$#))' and 'return $[!$#]' to return an error if no
> parameters given to function.
The problem with this is that it *always* returns from the function,
even when paramters are given.
If you actually want to do
On Mon, Jul 06, 2020 at 03:03:15PM +0300, Ilkka Virta wrote:
> On 6.7. 14:37, Greg Wooledge wrote:
> > On Sat, Jul 04, 2020 at 01:42:00PM -0500, bug-b...@trodman.com wrote:
> > > but your soln is simplier. I assume /dev/stderr is on non linux UNIX
> > > also.
>
On Mon, Jul 06, 2020 at 09:45:59PM -0400, Dale R. Worley wrote:
> bug-b...@trodman.com writes:
> > foo | tee >(cat >&2) | bar
>
> I do wonder how portable >( ... ) is in practice, versus the portability
> of /dev/stderr. Maybe I worry about the former because I'm not
> practiced in named-FIFO
On Tue, Jul 07, 2020 at 07:41:51AM -0400, Greg Wooledge wrote:
> On Mon, Jul 06, 2020 at 09:45:59PM -0400, Dale R. Worley wrote:
> > bug-b...@trodman.com writes:
> > > foo | tee >(cat >&2) | bar
> >
> > I do wonder how portable >( ... ) is in p
On Fri, Jul 10, 2020 at 10:14:38AM +0100, Chris Elvidge wrote:
> export PS1='\[${fcol[d]}${ecol[!!$?]}\][$?] \[${ucol[!!$(id
> -u)]}\]\h\[${fcol[b]}\]!\[${ucol[!!$(id -u)]}\]\u\[${fcol[w]}\]:(`tty|cut
> -d/ -f3-`):\D{%a %d %b %Y %I:%M %P %Z}:`pwd`\n\$\[${fcol[n]}\] '
>
> I somehow thought that [..
On Tue, Jul 14, 2020 at 06:32:44AM -0400, Jeffrey Walton wrote:
> $ ./audit-libs.sh /home/jwalton/tmp/ok2delete/lib
> ./audit-libs.sh: line 17: 22929 Segmentation fault (core dumped)
> $(echo "$file" | grep -E "*.so$")
This grep regular expression is not valid. The * symbol in a regular
expr
> > IFS="" find "$dir" -name '*.so' -print | while read -r file
> > do
> > if ! $(echo "$file" | grep -E "*.so$"); then continue; fi
> > echo "library: $file"
> >
> > done
Also, I forgot to point out: your "if" line is executing each of
the shared libraries that you find. Every one of th
On Fri, Jul 17, 2020 at 10:10:21PM +0800, Humanities Clinic wrote:
> When I run make (I run it with the -i option), I see the following
> output for the first invoked command:
>
> bison -y -d ./parse.y
>
> ./parse.y: warning: 1 shift/reduce conflict [-Wconflicts-sr]
>
> bison: /usr/local/Cellar/
On Tue, Jul 21, 2020 at 10:55:06AM +0300, M. Nejat AYDIN wrote:
> Also, shouldn't the tilde be expanded following
> $ echo ~:
> ? The colon terminates tilde-prefix in an assignment, but there is no
> assignment involved here.
Works for me.
unicorn:~$ echo ~:
/home/greg:
Also in POSIX mode.
On Tue, Jul 21, 2020 at 03:14:59PM +0300, M. Nejat AYDIN wrote:
> On 7/21/20 2:48 PM, Greg Wooledge wrote:
> > On Tue, Jul 21, 2020 at 10:55:06AM +0300, M. Nejat AYDIN wrote:
> > > Also, shouldn't the tilde be expanded following
> > > $ echo ~:
> > >
On Mon, Jul 27, 2020 at 01:31:32AM -0400, Dale R. Worley wrote:
> So it seems like the word splitting in "A=(X$Z)" is incorrect.
If the documentation doesn't support word splitting in that case,
then it's the documentation that will need to change, not the shell.
Word splitting in that context is
On Thu, Aug 06, 2020 at 02:14:07PM +0200, Jason A. Donenfeld wrote:
> On Thu, Aug 6, 2020 at 1:15 PM Oğuz wrote:
> > set -e o substfail
> > : <(sleep 10; exit 1)
> > foo
> >
> > Say that `foo' is a command that takes longer than ten seconds to complete,
> > how would you expect the sh
> > "Can bash please implement multidimensional arrays as I think they're
> > nifty and would like to use them."
> It seems that Chet has never been interested, and no one else has
> stepped up to contribute.
A large reason for this is because bash is a shell, not a programming
language. Another
On Wed, Aug 26, 2020 at 12:01:26AM -0400, Dale R. Worley wrote:
> open("/dev/stdout", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 EEXIST (File exists)
> write(2, "Error:", 18Error:) = 18
> write(2, "Cannot open \"/dev/stdout\" to wri"..., 56Cannot open "/dev/stdout"
> to write
1301 - 1400 of 1972 matches
Mail list logo
