Date:Sun, 18 Jun 2017 14:02:05 -0700
From:L A Walsh
Message-ID: <5946ea4d.8030...@tlinx.org>
| Side question: Why display that message if there are only
| NUL's at the end? I would think it normal for bash to
| use and read NUL terminated strings.
Files with
On Sat, 2017-06-17 at 20:23 -0400, Chet Ramey wrote:
> On 6/14/17 12:04 PM, tetsu...@scope-eye.net wrote:
> >
> >
> > This is relevant to my interests!
> >
> > So first off, the circular reference problem with "declare -n"
> > apparently doesn't exist in Korn Shell: If you "typeset -n x=$1", and
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 asked w
I'm trying to figure out a way to fuzz >>read -e -d ""<<, without having the
fuzzer break due to the temporary files created by fc.
While doing this, I noticed the oddities described below.
#1
Hit `C-x C-e' twice. The value of PATH seems to be ignored for the second
line.
dualbus@debian:~$ P
On 6/18/17 8:06 PM, Martijn Dekker wrote:
> (eval '(');echo $?
Thanks for the report. The parse error followed by EOF needs to call
YYABORT when the shell isn't reading input interactively.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'
bash-snap-20170616
$ (eval '(');echo $?
bash: eval: line 2: syntax error: unexpected end of file
0
The exit status is 0, but should be 1.
As far as I can trace it, this bug seems to have been introduced in
bash-20170511 snapshot.
- M.
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 asked why bash transformed input witho
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
On 6/18/17 5:02 PM, L A Walsh wrote:
> int dpi=$(ord $(<"$pixels_path" 2>/dev/null))
>
>
> This used to work but now works _unreliably_.
>
> (NOTE: I know that function won't work for values over 255,
> but hasn't been a problem yet, so haven't needed to fix it).
>
> Tried running it interact
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 "2>/dev/null" wasn't
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?
I tested on a couple of versions, and the behavior you describe didn't work:
dualbus@debi
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
12 matches
Mail list logo
