isabella parakiss wrote:
that's not true https://gist.github.com/fa4efd90376ff2714901e4429fdee734
read successfully reads the data, but then it's discarded by bash
It's discarded by bash because the read doesn't read 10
characters within the time limit. If you use -N 5, you get
you
I was checking to see if an associative array had a member:
echo $BASH_VERSION
4.4.5(1)-release
declare -A requires=([squid]="-d /var/cache/squid/run")
This works as expected:
if [[ ${requires[xxx]:-} ]]; then echo ok; else echo not; fi
not
But this did
Michał Górny wrote:
Hi,
While scanning our systems for executables that are installed u-w, I've
noticed this specific mode is used for bashbug explicitly. Is there
a good reason for doing that?
---
Doesn't it have execute permission? But it seems semi normal
for a system-"executable" t
John McKown wrote:
Not replying for Chet, who will have the definitive answer, I will say
that I, personally, think that is working as designed. ~ 0 (with space
between) is definitely the "not" operator. But without the middle
space, ~0, where there is a white space character in front of the
7; (and/or an env-based solution of something like
"BASH_WBC")? The latter might be usable to propagate a "Terminal's"
setting to a spawned program like bash or through 'ssh' to a remote
login shell.
Is that something that might be added-to or considered-for BASH (if it isn't
already doable in some way?)
-l
amp;1 |grep -v "$RE_filt" >&2 3>&1
(which of course doesn't work)
Is it possible/doable?
Tnx!
-l
Dennis Williamson wrote:
http://mywiki.wooledge.org/BashFAQ/047 (search for "stdout intact")
Thanks!
g in $(), but bash didn't like the parens...
At that point figured it was probably solved and asked onlist...
Thanks for the added input!
-l
x27; lines at the top (especially if they don't know what they
are for)...
Does that give you an idea of the usefulness vs. amount of
work to get everyone to do/accept it? :-)
Good idea though -- it's worked out reasonably well on
web docs.
-l
Andreas Schwab wrote:
On Jan 24 2017, "Brian 'geeknik' Carpenter" wrote:
<<$(()())|>_[$($(<<0)) crashes bash on Debian, Red Hat, FreeBSD, etc.
Worksforme with bash 4.4.
---
I duplicated it under bash 4.3.42, but not under 4.4.5.
-l
I noticed an error coming out of a script when I tried
to check an array's size w/unbound var checking enabled
(note my=declare, array='my -a')
First w/bash-4.3.42:
bash# try in subshell in case '-u' exits
array gv_ops=()
echo ${#gv_ops[@]} # existing var
0
Greg Wooledge wrote:
On Thu, Jan 26, 2017 at 01:11:25PM -0800, L A Walsh wrote:
Subject: Re: What is correct syntax to check for empty array?
The number of elements is 0 if the array is empty. So you would test
whether ${#array[@]} is 0.
set -u # now
If I set bash to complain about uninitialized variables
w/-u, I get inconsistent, and seemingly incorrect behavior:
echo $BASH_VERSION
4.4.5(1)-release
set -u
echo ${undefvar}
bash: undefvar: unbound variable
echo ${undefvar[@]}
# no message about unb
Grisha Levit wrote:
This seems to be the following change (from CHANGES)
>
|
a. Using ${a[@]} or ${a[*]} with an array without any assigned elements when
the nounset option is enabled no longer throws an unbound variable error.|
---
I see...
Tnx!
-l
27;s gives more write errors, and ctl-d exits the shell.
echo $TIMEFORMAT
%2Rsec %2Uusr %2Ssys (%P%% cpu)
history|wc
27169 125636 1170025
Anyone else able to reproduce this or is this just another
weirdism specific to my setup? *sigh*
tnx,
-l
Chet Ramey wrote:
On 2/20/17 12:40 AM, L A Walsh wrote:
In both 4.3.42(2)-release and
4.4.5(1)-release, I was listing my history (history cmd)
and hit control-C and got:
Do you have SIGINT trapped?
nope:
trap
trap -- '' SIGTSTP
trap -- '' SIGTTIN
tra
ptions seem
to have been meant to solve specific compat problems that
people needed, as they came up -- not as a new, long-term
feature to control various compat issues.
-l
Chet Ramey wrote:
On 3/4/17 12:53 AM, Misaki wrote
Full-width character, followed by at least one full word with a space after it.
Example: あa a
With trailing space.
This is a display artifact. If there is one physical space left on the
screen line, but the character to be printed occ
I have used relative paths to a 'base' and 'dest' to allow
comparisons/upgrades, etc, something along the lines of
(this is a rough-spur of the moment example):
cur=where I'm currently working
base=olddir
...
idea that no matter where I move in new tree, path from
'cur' is same as path from 'bas
I didn't see that this was caught and wasn't sure if
it was already covered in what I previously
posted this problem in a follow-up to a similar problem.
It may be the same bug, but I wasn't sure.
If I past the text in quotes into bash, bash tosses in
an extra character as evidenced by 'wc':
Eduardo Bustamante wrote:
On Mon, Mar 6, 2017 at 6:50 AM, L A Walsh wrote:
[...]
echo 'あa a '|wc -m
6
There should only be 5 characters.
use echo -n then.
$ echo -n 'あa a '|wc -m
5
---
Yup. I'm an idiot at times!
The thing was th
Chet Ramey wrote:
I can't reproduce this with bash-4.4, even when setting `direxpand'
before performing completion on a pathname beginning with `../'.
It is possible that you or your vendor compiled bash with directory
expansion enabled by default (--enable-direxpand-default), which
turns this
Pete Smith wrote:
The problem with: dirs, pushd, popd
...
Using an alias solution:
popd | sed 's/\s/\n/g' | nl
Um... don't you mean to use the alias command somewhere, like:
alias popd='builtin popd|tr " " "\n"'
Then it seems to work.
Is that what you mean by using an alias?
L A Walsh wrote:
Pete Smith wrote:
The problem with: dirs, pushd, popd
...
Using an alias solution:
popd | sed 's/\s/\n/g' | nl
Um... don't you mean to use the alias command somewhere, like:
alias popd='builtin popd|tr " " "\n"'
Th
Chet Ramey wrote:
On 4/18/17 9:35 AM, Eduardo Bustamante wrote:
Or now that I think about it, you can get away with these functions:
# masked builtins
dualbus@debian:~/foo/bar/baz$ pushd() { builtin pushd "$@" >/dev/null;
dirs -v; }; popd(){ builtin popd "$@" >/dev/null; dirs -v; }
T
I wanted to search for a file that had 'Tokyo' in the basename,
in all directories below a given point. I had been doing it 'find',
but thought globstar should work.
W/globstar set, I looked for:
ls **Tokyo*
(nothing)
ls ***Tokyo*
(nothing)
ls **Tokyo**Tokyo*
(nothing)
ls **/*Tokyo*
(found mult
Chet Ramey wrote:
On 4/28/17 8:09 PM, L A Walsh wrote:
ls **Tokyo*
(nothing)
ls ***Tokyo*
(nothing)
ls **Tokyo**Tokyo*
(nothing)
ls **/*Tokyo*
(found multiple matches (including the one I was
searching for))
Because the first two search for files containing the string `Tokyo' i
How might one programatically call a bash
function from readline, and pass information from that function
back into readline?
Also, is it possible to define a readline
function, or only use predefined ones?
Ex: On a keypress, I would like to be able to
redefine that key in ".bashrc" and have i
Eduardo Bustamante wrote:
For that, you'd use a combination of `bind -x', READLINE_LINE and
READLINE_POINT. For example, if you wanted a key sequence to uppercase
the whole rl_line_buffer (READLINE_LINE), then you'd:
You can do a lot of things with these two alone. I guess you can
emulate
It would be a useful upgrade besides being a "good world citizen" ;-).
For ID's, anyway, I think checking the 'ID Continue' binary property
would be the minimum. Could get more precise and check that
'ID Start' is set for chars starting an ID (that disallows
numbers, as being the start of an ID)
Eduardo Bustamante wrote:
On Thu, Jun 1, 2017 at 7:42 PM, L A Walsh wrote:
It would be a useful upgrade besides being a "good world citizen" ;-).
[...]
I honestly fail to see the usefulness of such upgrade. It'll just
increase the complexity of the parser, to g
dualbus wrote:
- People then have to test the new implementation, to ensure that there
are no regressions, and no new bugs introduced. I'm happy to volunteer
once there's a working implementation.
- There are some questions that must be answered first:
* How do you how to decode multib
Greg Wooledge wrote:
On Thu, Jun 01, 2017 at 09:31:24PM -0700, L A Walsh wrote:
Variable names like:
L??v -- (3 letter word pronounced like Leave), (most recent try...)
Here is a demonstration of the cost of what you are proposing. In my
mail user agent, your variable shows up as L
e
expected next month, or even "anytime" by a specific person (if they have
no interest in the work) I'd support them not doing it as long as they
allow someone more interested to do the work. Being open to doing it
yourself isn't required to be open to seeing something grow in specific
directions...
-l
Greg Wooledge wrote:
Here is a demonstration of the cost of what you are proposing. In my
mail user agent, your variable shows up as L??v.
Source code with your UTF-8 identifiers would no longer even be
READABLE
What display/OS do you have that you can't run UTF-8 on?
Still cu
John McKown wrote:
On Sat, Jun 3, 2017 at 4:48 PM, L A Walsh <mailto:b...@tlinx.org>> wrote:
Greg Wooledge wrote:
Here is a demonstration of the cost of what you are
proposing. In my
mail user agent, your variable shows u
dualbus wrote:
I hadn't realized that bash already supports Unicode in function names!
FWIW:
bash-4.4$
Lēv=?
Φ=0.618033988749894848
With this terrible patch:
dualbus@debian:~/src/gnu/bash$ PAGER= git diff
Clarification, please, but it looks like with your
patch below, U
George wrote:
On Mon, 2017-06-05 at 15:59 +0700, Peter & Kelly Passchier wrote:
On 05/06/2560 15:52, George wrote:
there's not a reliable mechanism in place to run a script in a locale
whose character encoding doesn't match that of the script
From my experience running such scri
George wrote:
On Mon, 2017-06-05 at 16:16 -0700, L A Walsh wrote:
George wrote:
On Mon, 2017-06-05 at 15:59 +0700, Peter & Kelly Passchier wrote:
On 05/06/2560 15:52, George wrote:
there's not a reliable mechanism in place to run a script in a
locale whose character encoding does
Greg Wooledge wrote:
On Tue, Jun 06, 2017 at 07:01:23AM -0700, L A Walsh wrote:
George wrote:
On Mon, 2017-06-05 at 16:16 -0700, L A Walsh wrote:
George wrote:
On Mon, 2017-06-05 at 15:59 +0700, Peter & Kelly Passchier wrote:
On 05/06/2560 15:52, Ge
Greg Wooledge wrote:
On Tue, Jun 06, 2017 at 12:02:41PM -0700, L A Walsh wrote:
Bash *is* the linux
shell. It's being adopted elsewhere, but it seems to have first grown
in use in the linux community.
Bash predates Linux. Bash was first released in 1989. Linux wasn't
rele
First) readonly & export by show vars in a re-usable format, however,
this doesn't work for functions.
Second) What is the official way to list functions w/their
flags+definitions
in a way reusable as input?
Third) How can one print the flags on a single function?
And a questio
Ooops... some more testing...
L
First) readonly & export by show vars in a re-usable format, however,
this doesn't work for functions.
---
It actually seems to be re-usable... though not nearly as
concisely as the var listing format.
Second) What is the official wa
Greg Wooledge wrote:
I don't know what you mean. A function is not a name=value pair.
The name is the name of the function, the value is
what the function does.
declare -f hw='() { echo "Hello World\n"; }'
The above has a name on the left side, and the value of the name
is on the right sid
Chet Ramey wrote:
Should mapfile silently drop the NULs?
Maybe add a flag to ignore NUL bytes that could be used in the 'read'
statement as well? If not specified, keep same behavior?
Greg Wooledge wrote:
What are you talking about? Consistency between what two things?
Are you allergic to newlines? declare -p uses raw newlines in its output
whenever it feels they are appropriate. Even in ordinary shell variables:
imadev:~$ x=$'foo\nbar'
imadev:~$ declare -p x
declare -- x="fo
Dethrophes wrote:
This would be a bad idea in the same way that having control characters in
filenames is a bad idea, just because you can do something doesn't mean you
should.
Not true. While POSIX has *discussed* disallowing control characters in
filenames, using Unicode in filenames is
Chris F.A. Johnson wrote:
On Fri, 9 Jun 2017, L A Walsh wrote:
First problem: If you are assigning a string to a variable,
you need to put quotes around the string.
You don't need to quote it unless it contains literal whitespace.
Not exactly true -- "any" type
Chris F.A. Johnson wrote:
A newline IS literal whitespace.
I'm glad you think so. I tend to agree, but I was clarifying for
those that might have a different definition.
Chris F.A. Johnson wrote:
On Fri, 9 Jun 2017, L A Walsh wrote:
First problem: If you are assigning a string to a variable,
you need to put quotes around the string.
You don't need to quote it unless it contains literal whitespace.
---
Not true if you want to reproduc
Chet Ramey wrote:
You are misunderstanding what that is supposed to do, or ignoring it.
`declare -p' quotes its output in a way that allows it to be reused as
shell input. Executing the output of `declare -p' will recreate the
variable with an identical value.
Re-use as shell input? That'
Charles Daffern wrote:
First problem: If you are assigning a string to a variable,
you need to put quotes around the string. That shows that "-p"
doesn't insert newlines:
> x="$'foo\nbar'"
> declare -p x
declare -- x="\$'foo\\nbar'"
You do not have any newlines in that string, so o
Clark Wang wrote:
I've checked the ssh process and it does not catch SIGTTIN and that's why
I'm confused.
From what I understand, a background process will automatically
block when it tries to read from STDIN. By definition, processes
become bg-processes by using '&'. I haven't loo
Clark Wang wrote:
On Tue, Jun 13, 2017 at 2:48 AM, L A Walsh wrote:
Clark Wang wrote:
I've checked the ssh process and it does not catch SIGTTIN and that's why
I'm confused.
From what I understand, a background process will automatically
block w
Chet Ramey wrote:
On 6/1/17 8:42 PM, L A Walsh wrote:
It would be a useful upgrade besides being a "good world citizen" ;-).
The only way this makes sense is to extend the allowable set of
characters from the portable character set to the current locale.
I'm g
Chet Ramey wrote:
On 6/2/17 6:23 PM, L A Walsh wrote:
As for unsupported systems, there is a reason they are no longer
supported. The world is already using UTF-8. It's only a few
luddites clinging to ascii as a last refuge. ;-)
What display/OS do you have that you can't ru
tetsu...@scope-eye.net wrote:
This is also why I think this should be an optional "encoding marker"
---
Why? If it was the current encoding, it wouldn't have high-bits
set. If it had any high bits set, it's fairly simple to
either presume or validate the script as UTF-8, as it is
self-sy
Chet Ramey wrote:
That's not relevant to the issue of whether or not a particular character
is classified as alphabetic in one locale and not another.
That isn't relevant either. Unicode declares the categories
that characters are in -- GLOBALLY. It doesn't vary by locale.
Even if a
Chet Ramey wrote:
On 6/13/17 8:35 PM, L A Walsh wrote:
Chet Ramey wrote:
That's not relevant to the issue of whether or not a particular character
is classified as alphabetic in one locale and not another.
That isn't relevant either. Unicode declares the categ
Greg Wooledge wrote:
Here is a demonstration of the cost of what you are proposing. In my
mail user agent, your variable shows up as L??v.
iso8859-15 was introduced in 1999 to replace iso8859-1 as it didn't
have the Euro symbol. I can set my system to use iso8859-15,
but not "-1
Chet Ramey wrote:
On 6/14/17 5:52 PM, L A Walsh wrote:
Chet Ramey wrote:
But people don't work in Unicode. They work in their own locale.
Ok, I have my locale set to latin9 (iso8859-15).
Attached is a pic ...
I am less concerned with how glyphs display in a console tha
Chet Ramey wrote:
On 6/15/17 11:22 AM, PePa wrote:
On 15/06/2560 22:03, Chet Ramey wrote:
I don't know other languages well enough to point one out, but
I can easily imagine that a particular character is an
"alphabetic" in, say, Mandarin, but doesn't exist in someone's
en_US characte
Chet Ramey wrote:
On 6/15/17 3:04 PM, L A Walsh wrote:
Two problems with locale-based rules are:
1) they differ based on local convention, potentially,
even down to what "side of the street" you live on, and
That's precisely what makes them valuable to users.
I think I've found why I keep getting random values for
my DPI on my X-server starting from **Cygwin**.
I read a binary value in the low byte in
the registry Dword (broken apart due to line length):
my -r HKLM='HKEY_LOCAL_MACHINE'
my -r MsWinNT='SOFTWARE/Microsoft/Windows NT'
my -r DPI_Px='Fo
Eduardo A. Bustamante López wrote:
On Sun, Jun 18, 2017 at 02:02:05PM -0700, L A Walsh wrote:
[...]
int dpi=$(ord $(<"$pixels_path" 2>/dev/null))
This used to work but now works _unreliably_.
In what version does this used to work?
It used to work when &quo
Chet Ramey wrote:
Bash has always stripped NULL bytes. Now it tells you it's doing it.
Why? Did I toggle a flag asking for the warning? Seems like it
was sorta sprung on users w/no way to disable it.
Side question: Why display that message if there are only
NUL's at the end? I would thi
Chet Ramey wrote:
On 6/18/17 6:59 PM, L A Walsh wrote:
Chet Ramey wrote:
Bash has always stripped NULL bytes. Now it tells you it's doing it.
Why? Did I toggle a flag asking for the warning? Seems like it
was sorta sprung on users w/no way to disable it.
Users
Pierre Gaston wrote:
Your response: you accuse him to lie to you.
Huh? Are you daft? Just because I can't find something about bash
corrupting input in google and ask where people have said this
was said is accusing someone of lying? Sorry, but I'm looking for
context to see exactly what
301 - 368 of 368 matches
Mail list logo
