On Mon, Sep 26, 2011 at 8:19 PM, Peng Yu wrote:
> Hi,
>
> I know that I should use =~ to match regex (bash version 4).
>
> However, the man page is not very clear. I don't find how to match
> (matching any single character). For example, the following regex
> doesn't match txt. Does anybody kn
On Mon, Oct 31, 2011 at 6:14 PM, Fernan Aguero wrote:
> Hi,
>
> please accept my apologies, as this is my first post here. I'm sure
> I'm asking a very stupid questions, but I'm kind of stuck with this
> ...
>
> The Problem: a badly written C program (mktrace) that doesn't accept
> input as usual.
You're missing a dollar sign.
On Mon, Nov 7, 2011 at 7:23 AM, Peng Yu wrote:
> Hi Clark,
>
>> What do you mean by "1 long argument"?
>>
>> [bash-4.2.10] # cat foo.sh
>> v=" a b c ( a'b | "
>> set -o noglob
>> a=( $v )
>> set +o noglob
>> for i in "${a[@]}"; do
>> echo "$i"
>> done
>> [bash-4.2.10] # bash foo.sh
>> a
>> b
On Jan 31, 2012 11:08 AM, "Ivan Yosifov" wrote:
>
> On Mon, 2012-01-30 at 20:16 +0200, Pierre Gaston wrote:
> > On Mon, Jan 30, 2012 at 8:01 PM, Ivan Yosifov
wrote:
> > > Hi everyone,
> > >
> > > I got an admittedly basic question but I'm really at my wits' end with
> > > this.
> > >
> > > How do
DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux dennis-pc 3.2.6 #3 SMP PREEMPT Tue Feb 21 03:27:27 CET 2012
x86_64 AMD Phenom(tm) II X6 1100T Process
Wrong list. Your question is not about Bash and it's not about a bug in
Bash.
You must have replied to the wrong message. The original was about sed, not
completion.
Aliases are intended for command line convenience. You should use
functions, which can be exported and are the correct thing to use in
scripts (and even from the command line).
"For almost every purpose, shell functions are preferred over aliases."
But, of course, you know that already.
On Apr 1
On Thu, Jul 12, 2012 at 1:57 PM, DJ Mills wrote:
> On Thu, Jul 12, 2012 at 2:19 PM, Dennis Williamson
> wrote:
>> s=łódź; echo "${s^^} ${s~~}"'
>> łóDź ŁÓDŹ
>>
>> The to-upper and the undocumented toggle operators should produce
>> identical
On Nov 25, 2012 1:37 AM, "Rene Herman" wrote:
>
> Good day.
>
> I know that bash arrays are 1 dimensional -- but are there any plans for
providing multi-dimensional arrays?
>
> I'm currently writing a larger bash script to manage my (ogg vorbis)
music collection, including maintaining tags. Vorbis
On Nov 26, 2012 2:48 PM, "Chet Ramey" wrote:
>
> On 11/26/12 12:11 PM, Sam Liddicott wrote:
>
> > I explained how in the lines of my response that you deleted.
> >
> > It is potentially useless because:
> >
> > 1. it is non-obvious, most users will not expect this behaviour (unless
> > already ini
On Jun 13, 2013 4:09 PM, "Linda Walsh" wrote:
>
>
>
> Greg Wooledge wrote:
>>
>> On Thu, Jun 13, 2013 at 12:58:02PM -0700, Linda Walsh wrote:
>>>
>>> So how can my showsize function be mangling the input in a way that
>>> prevents proper execution, but isn't recorded by bash?
>>
>>
>> What makes y
On Sat, Sep 7, 2013 at 12:05 PM, Edik Bondarenko
wrote:
> I am added function `discard_multiline_comments` which disables code
> between /* and */ (C-style comments).
> The body of the function is located in the file y.tab.c : 5140 .
> Can this functionality be added in the next release ?
>
I did
On Sep 8, 2013 10:44 AM, "hanzlik" wrote:
>
> Configuration Information:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/l
On Apr 14, 2014 11:52 AM, "Dave Rutherford" wrote:
>
> On Mon, Apr 14, 2014 at 12:22 PM, David Binderman
wrote:
> > Anyone experienced looking at the code will always need to examine it
> > more closely to find out why it's a good idea in this case to use an
array
> > index and *then* sanity chec
On Jun 4, 2014 2:23 PM, "Jens Stimpfle" wrote:
>
> Hi, please Cc: me as I'm not subscribed.
>
> When I abort a bash prompt using Ctrl-c, the $? variable is set to 130
> just as if a job had been aborted. To illustrate, some terminal
> contents:
>
> jfs@knirps:~$ echo Hello
> Hello
> jfs@knirps:~$
On Jun 9, 2014 10:41 AM, "Thibault, Daniel"
wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-g
On Jun 19, 2014 5:00 PM, "Tim Friske" wrote:
>
> Hi,
>
> first I want to thank you for your help.
>
> While searching for an alternative I came up with the following code
> which does not work when I have the "shopt -os errexit" command line
> at the top of my script:
>
> read -d '' -r foobar < bl
On Sep 12, 2014 6:42 PM, "Ralf Goertz" wrote:
>
> Hi,
>
> Why do I need cat (the second on) here?
>
> $ echo first >file1
> $ echo second >file2
> $ (for i in file[12] ; do cat "$i" > /dev/stdout ; done) | cat > both
>
> $ cat both
> first
> second
>
>
>
> If I omit the "| cat" after the loop
On Sep 12, 2014 7:12 PM, "Bob Proulx" wrote:
>
> Ralf Goertz wrote:
>
> Since you have used an invalid address I assume you are reading the
> mailing list via a web archive or other means and did not CC you.
>
> > Why do I need cat (the second on) here?
>
> You don't.
>
> > $ echo first >file1
>
On Tue, Sep 16, 2014 at 2:03 AM, Ralf Goertz wrote:
> Am Sat, 13 Sep 2014 12:53:48 -0600
> schrieb Bob Proulx :
>
>
> > Dennis Williamson wrote:
> > > Bob Proulx wrote:
> > > > { for i in file[12] ; do cat "$i" ; done ;} > both
>
For those who might be interested, here's a much simpler function that
exhibits the same kind of leak and doesn't involve nested functions.
fd_leaker() { while :; do read a < <(pwd); c=(/proc/$$/fd/*);
c=${...@]}; echo $c; done; }
For some reason, adding "(exit 0); " right before the "done" seems
As Chet said, use internal variables that are unlikely to conflict.
# Param: $1 variable name to return value to
blackbox() {
local __bb_a# internal: __, blackbox: bb, a: _a
eval $1=bar
}
f() {
local a
blackbox a
echo $a
}
f# no conflict
I
ction can be as simple as that.
Thanks, Pierre, by the way, for the workarounds. I hadn't considered
using indirection that way.
On Sat, May 1, 2010 at 6:21 AM, Freddy Vulto wrote:
> On 100501 12:40, Pierre Gaston wrote:
>> On Sat, May 1, 2010 at 12:26 PM, Dennis Williamson wrote:
&g
In Bash 3.2.0(1)-release, "local" displays local variables that do and
do not have values. In Bash 4.0.33(1)-release and 4.1.0(1)-release
only those with values are printed. Oops.
f () { local var1 var2=abc var3=; local; }; f
Bash 3:
var1=
var2=abc
var3=
Bash 4:
var2=abc
var3=
So it looks like
I would discourage the use of "l" (ell) as a variable name for readability.
I like the fact that _blackbox_called_by uses a parameter rather than
parsing the caller's name. This allows you to permit multiple callers
to a common private function, if needed. However, I'm assuming that
you will name
History expansion is performed before variable expansion.
>From man bash:
History expansion is performed immediately after a complete line
is read, before the shell breaks it into words.
and
! Start a history substitution, except when ***followed by a
blank***, newline, carriage
To make your example work try:
$ b=a[*]
or
$ b...@]
Otherwise, your indirection is telling b to look at a as a scalar.
This would give the same result:
$ echo $a
x
On Thu, Jul 29, 2010 at 3:55 PM, Bernd Eggink wrote:
> It seems that indirect expansion doesn't work with arrays:
>
> $ a=(x y z
Oops, sorry, that converts all of a to a scalar b so ${b[0]} gives "x
y z" and ${b[1]} gives nothing.
On Thu, Jul 29, 2010 at 7:16 PM, Dennis Williamson
wrote:
> To make your example work try:
>
> $ b=a[*]
>
> or
>
> $ b...@]
>
> Otherwise, your indirection
If I do the echo line twice, I get a segfault in both Bash
4.0.33(1)-release and 4.1.0(1)-release.
And you're right about being evaluated twice.
On Sun, Aug 1, 2010 at 3:59 PM, Bernd Eggink wrote:
> Am 01.08.2010 13:06, schrieb Andrew Benton:
>
>> Also good. Now try converting it to lower case w
It's called a "here string".
On Mon, Jul 26, 2010 at 8:02 PM, Linda Walsh wrote:
> Huh. Triple redirect... Thanks!
>
>
> On 7/26/2010 5:53 PM, Chet Ramey wrote:
>> On 7/26/10 6:25 PM, Linda Walsh wrote:
>>> I don't know if there's an easy way, but if not would you consider an
>>> RFE --
>>>
>>>
while is a compound command. Only simple commands can have preceding
variable assignments. From man bash:
The environment for any simple command or function may be augmented
temporarily by prefixing it with parameter assignments, as described
above in PARAMETERS. These assignment statement
I can't reproduce your problem. Does this work?:
three=$(< data)
echo three=$three
On Fri, Aug 6, 2010 at 12:31 PM, John Kelly wrote:
>
>>bash --version
>>GNU bash, version 4.1.7(1)-release (i586-pc-interix3.5)
>
> #! /usr/local/bin/bash
>
> one=`cat data`
> echo one=$one
>
> two=$(cat data)
> e
However, if your pipe is in a command substitution or other subshell,
PIPESTATUS won't be useful. You'll have to use pipefail.
$ set +o pipefail
$ var=$(false | true)
$ declare -p PIPESTATUS# shows the status of the assignment, not the "false"
declare -a PIPESTATUS='([0]="0")'
$ var=$(false |
>This leap of illogic is beyond my ken. As a counterexample, "\x{...}"
>escape can consume an unlimited number of bytes while producing a
>single byte.
It only consumes two bytes on my system (or one if it's followed by
another escape or a closing quote).
> Because the documentation says "backsla
If you're writing a Bash-specific script then it's preferable to use
double square brackets (see http://mywiki.wooledge.org/BashFAQ/031).
if [[ -f $file ]]
then
do something
fi
I prefer forms using the fewest number of semicolons, but I really
don't think it matters. Consistency is more impor
One workaround would be to bind the keystroke to a macro that inserts
a comment character at the beginning of the line before doing
edit-and-execute-command. Then when you exit the editor the comment
will be "executed" then you can press up arrow to retrieve the line
and delete the comment characte
On Tue, Aug 24, 2010 at 2:44 AM, Joachim Schmitz
wrote:
> Edward Peschko wrote:
>>
>> All,
>>
>> I've been working lately at upgrading my debugging tools and
>> procedures, and have come to looking how I can improve debugging
>> bash.
>> I know about bash -x , but its terribly annoying because, ev
PROMPT_COMMAND doesn't create a subshell.
xyz () { ((num++)); date; echo -n "num: $num"; }
PROMPT_COMMAND='xyz'
PS1=' '
On Wed, Aug 25, 2010 at 11:20 AM, E R wrote:
> I've been trying to get a function called from PS1 to set a variable, e.g.:
>
> num=1
>
> function xyz {
> ((num++))
> date; ec
On Fri, Sep 3, 2010 at 3:12 PM, Philip Prindeville
wrote:
> On 9/3/10 10:44 AM, Eric Blake wrote:
>>
>> On 09/02/2010 04:44 PM, Philip Prindeville wrote:
>>>
>>> I wanted to check in and see if there was a chance of this feature being
>>> accepted upstream before I spent any time on it... so here
Use return instead of exit when you have an error and you're sourcing
the script. You can make it conditional.
Try setting OPTIND=1 to make your script work when it's sourced.
Initialize your script's variables since they will be carried over
between runs when you source the script.
#!/bin/bash
i
OK, my magic error corrector chose this as its output:
bash -c 'cd foobar' && ci filename
Is that what you were hoping for?
There's a big difference between a compiler and an interpreter. The
former can afford to take the time to do some of the kinds of things
that you describe. Those same thin
On Sun, Sep 26, 2010 at 2:31 PM, Christopher Roy Bratusek
wrote:
>> Style is a matter of taste, but I think this is equivalent (not tested):
>>
>> xrm () {
>> for path in "$@"; do
>> test ${path:0:1} == - && local RMO+="$path " && continue
>> for try in "$path"
On Sun, Sep 26, 2010 at 3:42 PM, Christopher Roy Bratusek
wrote:
> btw. How can I remove the last arguement ${!#} ?
>
> I tried args=${@:-${!#}} but that won't work.
>
> Chris
>
>
>
That says substitute the last argument if there are no arguments
(pretty much impossible).
Try this:
args=${@:1:$
On Mon, Oct 4, 2010 at 7:26 PM, Robert Citek wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
>
On Nov 5, 2017 7:05 PM, "積丹尼 Dan Jacobson" wrote:
$ help shopt
shopt: shopt [-pqsu] [-o] [optname ...]
Set and unset shell options.
Change the setting of each shell option OPTNAME. Without any option
arguments, list all shell options with an indication of whether or not
each
is
On Sat, Mar 24, 2018, 11:45 AM Clark Wang wrote:
> Hi Chet,
>
> Today I compiled bash5 (using default configuration) from the devel branch
> (f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks
> one of my rc files. After some time of debugging I have the following
> minimal
On Sat, Mar 24, 2018, 12:23 PM Dennis Williamson <
dennistwilliam...@gmail.com> wrote:
>
>
> On Sat, Mar 24, 2018, 11:45 AM Clark Wang wrote:
>
>> Hi Chet,
>>
>> Today I compiled bash5 (using default configuration) from the devel branch
>> (f602026a0ce
On Tue, Sep 25, 2018, 7:17 PM L A Walsh wrote:
> It struck me as it might be convenient if 'shift' could take an optional
> arrayname as an argument. Would that be possible or would it cause some
> incompatibility?
>
> i.e.
>
> > set one two three four five
> > dcl -a ARGV=("$@")
> > shift AR
On Sat, Jan 5, 2019, 4:05 PM Robert Hailey
> To the most excellent bash maintainers:
>
> I have found, what I consider to be a bug, in the following version of
> bash:
> * bash-4.4.23-1.fc28.x86_64
>
> It is related to this error message:
> * "return: can only `return' from a function or sourced s
On Tue, Jan 8, 2019, 3:10 PM Configuration Information [Automatically generated, do not change]:
> Machine: i686
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -fstack-protector -Wno-parentheses -Wno-format-security
> uname output: Linux bongo 2.6.32-042stab134.8 #1 SMP Fri Dec 7 17:16:09
>
On Fri, Jan 25, 2019, 9:51 PM Robert White On 1/22/19 10:23 PM, Chet Ramey wrote:
> > On 1/22/19 3:32 PM, Robert White wrote:
> >> Howdy,
> >>
> >> The following cannot work because, for some reason, the array subscript
> >> parser insists on doing math on array indices even when the array is
> >>
etc
Most likely we need a check for the existence of O_CLOEXEC during the
configure stage and then adjust ./examples/loadables/Makefile.in to
remove or skip the example file.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On Fri, Feb 15, 2019, 10:46 PM L A Walsh
> I printed the various declares using:
>
> declare -p |& more
>
> One of the early entries is:
>
> declare -A BASH_ALIASES=()
>
> Yet if I type 'alias |& wc, I see 56 lines starting with alias.
>
> I _thought_ BASH_ALIASES was suppose to hold the aliases
>
On Sun, Feb 17, 2019, 3:10 PM L A Walsh
>
> On 2/16/2019 4:57 AM, Robert Elz wrote:
> > Date:Fri, 15 Feb 2019 22:21:25 -0800
> > From:L A Walsh
> > Message-ID: <5c67abe5.1030...@tlinx.org>
> >
> > | Thought about thatrestarted a fresh shell. Same same.
> >
On Sun, Feb 17, 2019, 6:01 PM L A Walsh
>
> On 2/17/2019 2:19 PM, Dennis Williamson wrote:
> >
> > So it really is a bug of some sort, not that I use BASH ALIASES
> > for anything. Was going to, but ... and you're right, lots of
> &
I will try again from the sources but am curious if there is a
definitive list of dependencies that bash 5.0.7 will need/want ?
Dennis
On 4/22/19 1:01 PM, Greg Wooledge wrote:
On Mon, Apr 22, 2019 at 12:54:28PM -0400, Dennis Clarke wrote:
I see these are all published in the gnu ftp server :
https://ftp.gnu.org/pub/gnu/bash/bash-5.0-patches/
So I will try again from the sources but am curious if there is a definitive
On 4/22/19 1:26 PM, Greg Wooledge wrote:
On Mon, Apr 22, 2019 at 01:21:38PM -0400, Dennis Clarke wrote:
I don't think bash 5 has hit Debian sid yet.
It's not only in sid; it's also in buster.
Here's the relevant excerpt from the changelog:
bash (5.0-1) unstable; urgency=
has left the building and all the great Solaris guys were
taken to the chemical shed and shot. Oracle Solaris is a dead product.
Good luck getting the userbase back. Oracle did *everything* to kill it.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On Sat, May 4, 2019, 3:39 PM wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
> -DCONF_V
On Tue, May 21, 2019 at 3:04 AM Henning wrote:
> On 20/05/2019 15:38, Chet Ramey wrote:
> > On 5/19/19 10:43 AM, Henning wrote:
> >> I don't like to have dozens of key bindings I never use. Currently I
> >> am issuing lots of lots of bind -r/-u commands to get rid of the
> >> default bindings. Th
0-007_SunOS5.10_sparc64vii+.002/examples/loadables'
gmake: [Makefile:824: install] Error 2 (ignored)
beta #
Yeah well. Okay.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
On 5/25/19 5:55 PM, Chet Ramey wrote:
On 5/25/19 2:06 PM, Dennis Clarke wrote:
On any Solaris boxen there really isn't O_CLOEXEC so even after a neat
compile and test the install will blow up.
http://lists.gnu.org/archive/html/bug-bash/2019-02/msg00167.html
You can use the patch there
On Sun, Jun 23, 2019, 5:31 AM bitfreak25 wrote:
> OS: Arch Linux 5.1.12-arch1-1-ARCH (tty1)
> Bash-Version: 5.0.7(1)-release
> localization: de_DE.UTF-8 UTF-8
> keymap: de-latin1-nodeadkeys
>
> Description:
> The command "cat /etc/localtime" was called in a tty-terminal. After that
> some charact
On Sun, Jun 23, 2019, 7:18 AM bitfreak25 wrote:
> On Sun, 23 Jun 2019 06:04:29 -0500
> Dennis Williamson wrote:
>
> > On Sun, Jun 23, 2019, 5:31 AM bitfreak25 wrote:
> >
> > > OS: Arch Linux 5.1.12-arch1-1-ARCH (tty1)
> > > Bash-Version: 5.0.7(1)-releas
>From the bc man page on Ubuntu:
This version of bc was implemented from the POSIX P1003.2/D11 draft and
contains several differences and extensions rela‐
tive to the draft and traditional implementations.
and
LANG environment
This version does not conform to the POSIX
n/bc -l
a = 0,1
syntax error on line 1, teletype
a = 0.1
b = 0.01
c = a + b
c
.11
c(c)
.99395609795669685035
corv $
Well now. That is XPG6 compliant bc on Solaris 10 sparc.
It could care less about locale it seems. Nifty.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/bc.html#tag_20_09_16
"The bc utility always uses the ( '.' ) character to represent
a radix point, regardless of any decimal-point character specified as
part of the current locale.
Good catch. I went by the bc man page t
On 7/12/19 3:50 PM, Chet Ramey wrote:
On 7/12/19 3:46 PM, Dennis Clarke wrote:
uh huh ...
LC_NUMERIC
This category specifies the decimal and thousands
delimiters. The information corresponding to this
category is stored in a database
On 7/12/19 4:26 PM, Martijn Dekker wrote:
Op 12-07-19 om 21:46 schreef Dennis Clarke:
Well the man page for XPG6 bc in Solaris 10 claims :
ENVIRONMENT VARIABLES
See environ(5) for descriptions of the following environment
variables that affect the execution of bc: LANG, LC_ALL
On Fri, Jul 12, 2019, 3:46 PM L A Walsh wrote:
> On 2019/07/12 11:51, Eli Schwartz wrote:
>
>
> find_cmds() {
> for c in "$@"; do
> type -P $c >&/dev/null || {
> Pe "$0#$LINENO: Cannot find %s", "$c"
> exit 1; }
> alias $c=$(type -P $c);
> done
> }
>
>
>
This is a perfect
On 7/12/19 4:45 PM, Chet Ramey wrote:
On 7/12/19 4:26 PM, Martijn Dekker wrote:
Op 12-07-19 om 21:46 schreef Dennis Clarke:
Well the man page for XPG6 bc in Solaris 10 claims :
ENVIRONMENT VARIABLES
See environ(5) for descriptions of the following environment
variables that
On 7/12/19 4:45 PM, Chet Ramey wrote:
On 7/12/19 4:26 PM, Martijn Dekker wrote:
Op 12-07-19 om 21:46 schreef Dennis Clarke:
Well the man page for XPG6 bc in Solaris 10 claims :
ENVIRONMENT VARIABLES
See environ(5) for descriptions of the following environment
variables that
XLY_CORRECT then the shell can make coffee for you. Personally I am
of the opinion that a tool in the Linux/UNIX world should do one thing
well and then stop. Otherwise we may as well just make Windows 12.
Dennis
On 8/29/19 2:22 PM, Chet Ramey wrote:
BASH PATCH REPORT
=
Small problem when building bash-5.0-011 out of tree is that the
file lib/glob/smatch.c is set chmod 600 and thus not readable by
the build user.
--
Dennis
On Tue, Oct 22, 2019, 8:10 AM younes berramdane
wrote:
> Hello,
> I have found a seg in the history of bash while I was doing a project for
> my school,
> (Put fc -s at the last command of the history file [~/.sh_history] for
> bash posix or [~/.bash_history] for bash then launch bash and execute
name on it there Chet.
Anyways ... just wanted to utter a reminder that the tarball has some
restricted ./lib/glob/smatch.c in there as well as other ... stuff.
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
Forwarded Message --
On Tue, Nov 26, 2019, 5:46 AM Алексей Шилин wrote:
> В Пн, 25/11/2019 в 18:29 -0800, L A Walsh пишет:
> > Multi-byte or not, invisible characters need to be enclosed
> > as documented under 'PROMPTING':
> >
> > \[ begin a sequence of non-printing characters, which could
> >
On Tue, Nov 26, 2019, 9:50 AM Алексей Шилин wrote:
> В Вт, 26/11/2019 в 07:35 -0600, Dennis Williamson пишет:
> > You have printable characters enclosed. For example, \u. _Each_
> > sequence of unprintable characters needs to be separately enclosed
> > _without_ enclosi
On Fri, Nov 29, 2019, 10:40 AM Nikolaos Kakouros wrote:
> Using bash version:
>
> GNU bash, version 5.0.11(1)-release (x86_64-pc-linux-gnu)
>
>
> Trying to map Backspace to execute a function, I try to do:
>
> bind -x '"Rubout": my_func'
>
> This, as expected, binds the string 'Rubout' to the fun
On Sat, Nov 30, 2019, 11:24 AM Chet Ramey wrote:
>
Readline binds the terminal special characters if the variable
> `bind-tty-special-chars' is set, and it's set by default.
>
Wow, that's been in Bash a long time and I never noticed it! Thanks!
>
On Wed, Jun 17, 2020, 5:07 PM wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. -fstack-protector-strong
> -Wformat -Werror=format-security
On Thu, Jun 18, 2020, 6:03 PM Bryan Henderson
wrote:
> ...
Any ideas on how I could see
> the raw character stream sent to a terminal?
>
>
Try the xev program. It will show X events and may reveal the keypresses
you're interested in.
>
On Sun, Jun 28, 2020, 8:50 AM felix wrote:
>
>_out=$(date -d "$_string" +%s)
> many time in same script, I run something like:
>
> _fifo=$(mktemp -u /tmp/fifo-)
> mkfifo $_fifo
> exec 9> >(exec stdbuf -o0 date -f - +%s >$_fifo 2>&1)
> exec 8<$_fifo
> rm $_fifo
>
>
= (char *)NULL;
_rl_term_kh = _rl_term_kH = _rl_term_at7 = _rl_term_kI = (char *)NULL;
_rl_term_so = _rl_term_se = (char *)NULL;
#if defined(HACK_TERMCAP_MOTION)
_rl_term_forward_char = (char *)NULL;
#endif
For reasons that I can not yet figure out sh_get_env_value ("TER
On 12/31/20 12:31 AM, Chet Ramey wrote:
> On 12/29/20 7:28 PM, Dennis Clarke wrote:
>>
>> Firstly as a minor nit that seems to re-appear yearly there are still
>> source files in the release tarballs that are not readable to a normal
>> user :
>>
>> #
>
uot; will result in the segfault.
Also, Chet has no access to the real hardware and thus looking at this
on x86 is like looking at the problem with a Raspberry Pi. Not the same
at all. Perhaps a nightly buildbot would help here? It certainly is a
trivial matter to setup a small zone on an Oracle box here and then let
it run.
Dennis
On Thu, Oct 30, 2014 at 1:45 PM, Daniel Colascione
wrote:
>
> Sure, you might argue that users should paste into a trusted
> intermediate location --- say a text editor --- inspect the code, and
> then paste into the shell. That would be the prudent thing to do, but
> users don't actually *do* th
On Fri, Dec 12, 2014 at 12:32 PM, Bob Proulx wrote:
> Greg Wooledge wrote:
> > David J. Haines wrote:
> > > When started interactively, bash sets the extglob shopt; however, that
> > > fact seems to have been overlooked in the manpage.
> >
> > This is a compile-time setting. Your vendor probably
On Thu, Apr 16, 2015 at 6:51 PM, Guillermo Buritica Tobon <
gburitic...@gmail.com> wrote:
> Hi All.
>
> H have the next bash script code.:
>
> #!/bin/sh
> # Pring OK on empty input,
> # Print input on non-empty input
>
> read INPUT
> if [ -z "$INPUT" ]; then
> echo OK
> else
> echo
On Fri, Apr 17, 2015 at 8:55 AM, Eduardo A. Bustamante López <
dual...@gmail.com> wrote:
> > Always quote your variables. The problem comes from
> >
> > echo $INPUT
> >
> > which should be
> >
> > echo $INPUT
>
> Someone derped. It *should* be
>
> echo "$INPUT"
>
> --
> Eduardo Bustamante
> https
On Tue, Apr 21, 2015 at 2:44 PM, Dr Alun J. Carr
wrote:
> There appears to be a bug in bash when using a variable in curly brace
> expansion, e.g., {1..$n}. I have put the two following test scripts in the
> attached files looper1.sh and looper2.sh:
>
> #looper1.sh
> for i in {1..4}
> do
> ec
I'm trying to put a command in a variable, but the complex cases always
fail! : http://mywiki.wooledge.org/BashFAQ/050
Eval command and security issues : http://mywiki.wooledge.org/BashFAQ/048
On Mon, May 25, 2015 at 2:33 PM, wrote:
> Configuration Information [Automatically generated, do not c
On Tue, Jun 2, 2015 at 5:47 PM, Dave Rutherford
wrote:
>
> It is ironic yet somehow appropriate that a fusion energy center
> should be having such a 1997 sort of problem today. But
> truly, my sympathies. :-)
>
> Dave
>
How about a nuclear plant having a '70s kind of problem?
https://ca.linke
On Sat, Jun 27, 2015 at 2:48 PM, Nathan Neulinger
wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-red
On Thu, Aug 6, 2015 at 12:45 PM, Valentin Schmidt wrote:
> From: v...@posteo.org
> To: bug-bash@gnu.org,b...@packages.debian.org
> Subject: bash displays strange characters after base64 decoding
>
> Configuration Information:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:
On Tue, Sep 1, 2015 at 12:50 PM, Greg Wooledge wrote:
> On Tue, Sep 01, 2015 at 12:50:23AM -0400, Clint Hepner wrote:
> > Repeat-By:
> >
> > foo=bar
> > bar=5
> > echo $(( foo ))# produces 5
> > echo $(( foo++ )) # produces 5
> > echo $foo # produces 6, not bar
>
On Tue, Sep 1, 2015 at 3:23 PM, Greg Wooledge wrote:
> On Tue, Sep 01, 2015 at 03:13:57PM -0500, Dennis Williamson wrote:
> > The version of dash I have handy (0.5.7) has math support which IMHO is
> > broken:
> >
> > $ foo=bar
> > $ bar=5
> > $ echo $foo
101 - 200 of 237 matches
Mail list logo
