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 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:
> > 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
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
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 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 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
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 lin
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 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
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
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 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
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
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
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
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
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 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
Also, of import in any terminal question is the content of your
prompt (PS1 variable).
See https://mywiki.wooledge.org/BashFAQ/053
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.
>
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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'
Or something like printf '%q\n' "${myvar:0:2}"
since I would assume
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
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 10, 2020 at 09:44:31AM +, Raffaele Florio via Bug reports for
the GNU Bourne Again SHell wrote:
> Indeed the functions called by arithcomp cause the evaluation of the supplied
> arithcomp function argument, potentially fed by user input.
> Give in input "x=42,xyz=UID" to the
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
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
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 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
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
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
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 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 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
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);
> > +
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 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
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 holes. I sug
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:
>
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
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 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
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
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
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
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 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 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 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
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
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 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 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
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 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
>
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
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 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
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 to e
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 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 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
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 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
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 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\
> >
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
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
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
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
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, 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
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 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
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
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
>
> (IFS=; printf '%s
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 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
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
On Wed, Oct 02, 2019 at 03:11:18AM -0700, L A Walsh wrote:
> > Bash allows a child of itself (a subshell) to read the commands.
> > GNU find -exec uses /bin/sh to run it.
> > zsh and csh both use /bin/sh to run it, I think.
> So if a user has 'rbash' in /etc/passwd, they might get a real
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 shebang-less script, this should fix it up:
> >
> Suppose the shebang-less script is being run by an
On Mon, Sep 23, 2019 at 09:02:47PM +0700, Robert Elz wrote:
> There is no real standard for this - NetBSD has deprecated the -depth
> operator (which never really was one) and replaced it by a -d option
> which makes much more sense (-depth never really was the right way to
> do it). -depth (the
On Fri, Sep 20, 2019 at 01:40:00PM +0800, hk wrote:
> Description:
> On section 3.2.4.2 of Bash Reference Manual, the example on*
> [[...]]* (page 13 in the PDF) is incorrect. Specifically, the example say *[[
> $line =~ [[:space:]]*?(a)b ]]* will match values like *'aab'* and*
>
On Fri, Aug 30, 2019 at 06:03:37PM -0600, Ray Sutton wrote:
> The issue is on a late 2013 MBP running MacOS 10.14.6 and
> bash -version reports 5.0.11(1)-release (x86-64-apple-darwin18.6.0)
>
> The error is occuring in my .bash_profile and reports as
>
> -bash: declare: -g: invalid option
You
On Thu, Aug 15, 2019 at 05:26:03PM +0200, Léa Gris wrote:
> Is there a way to control the order of entries in an associative array?
No.
> What rules applies to the order of entries?
None.
If you require both an associative array and an ordered list, then you
will need two different data
On Thu, Aug 15, 2019 at 12:37:01PM +0300, jarno.s...@saunalahti.fi wrote:
> https://www.gnu.org/software/bash/manual/html_node/Arrays.html tells
> "unset name[subscript] destroys the array element at index subscript."
>
> But if there is a file named names, nameu ,nameb, namec, namer, namei,
501 - 600 of 1728 matches
Mail list logo
