Greg Wooledge wrote:
Bash has only three choices that I can think of: it can silently drop the
NUL bytes behavior), it can drop ALL of the bytes and return an
error, or it can drop the NUL bytes with a warning (4.4 behavior).
now who is being disingenuous? It was silent not just in 4.3, b
Eric Blake wrote:
On 09/19/2016 11:58 AM, Greg Wooledge wrote:
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline)
bash-4.4: warning: command substitution: ignored null byte in input
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline 2>/dev/null)
wooledg@wooledg:~$
Or:
$ x=$(< /proc/$$/cmdline tr -d
� wrote:
Yes, the can be overridden in /etc/sysctl.d. But I am going to modify
the troublesome scripts in the $50k software and leave the security of
the OS intact. Thanks.
Actually, setting them to "1", is not "leaving the OS security intact" --
it's adding new, non-default security
Dan Douglas wrote:
The 4.4 changes will make aliases even more interesting.
---
Oh? Why is that? I.e. what's happening to aliases that
will make them more "interesting"?
BTW, are you using "interesting" in the same way as the
saying "May you live in interesting times"?
Grisha Levit wrote:
The manual references these values being set, not just declared, so
maybe should check for invisible_p?
---
Why? I.e. what were you wanting to happen?
Noticeable for example because this works:
$ set +o posix; f() { local POSIXLY_CORRECT=; shopt -p -o posix; }; f;
Stephane Chazelas wrote:
2016-02-25 03:03:41 -0800, Linda Walsh:
Stephane Chazelas wrote:
$ time bash -c 'while ((SECONDS < 1)); do :; done'
bash -c 'while ((SECONDS < 1)); do :; done' 0.39s user 0.00s system 99% cpu
0.387 total
Sorry I
Stephane Chazelas wrote:
$ time bash -c 'while ((SECONDS < 1)); do :; done'
bash -c 'while ((SECONDS < 1)); do :; done' 0.39s user 0.00s system 99% cpu
0.387 total
That can take in between 0 and 1 seconds. Or in other words,
$SECONDS becomes 1 in between 0 and 1 second after the shell was
st
Greg Wooledge wrote:
On Mon, Feb 15, 2016 at 07:59:21PM -0800, Linda Walsh wrote:
Obviously, If I could precook the array into
a hash, I'd think it would be faster... but
the "cooking part", I think, is the high
overhead part.
Redesign the entire script so t
Dan Douglas wrote:
Ah so `arr+=([a]=x [b]=y)` will no longer be the same as `arr+=([a]+=x
[b]+=y)`? I never liked that for associative arrays because the only
workaround was to do multiple arr[key]= assignments to update or add
more than one element at a time.
My thinking was that this is due
I has a little 4 line func that returns true or false
if a string was in an array
I came up with a different way of doing it, that I
though might be faster... but...
putting them in a file and running loops on them.
(times below). Obviously, my feeling for what might
be faster was way wrong. w/m
Linda Walsh wrote:
I seem to remember some discussion of this before --
not being able to use -v to check if a hash was defined,
but having it "work"(?) w/arrays?
So instead of "-v" on an array/hash name only looking at the
value of [0] (for either), can it be enhanc
Chet Ramey wrote:
On 2/15/16 12:35 PM, Linda Walsh wrote:
Bash Version: 4.3
Patch Level: 42
Release Status: release
Description:
[Detailed description of the problem, suggestion, or complaint.]
When I create hash and later add keys using the form
"HASH+=([key]=
Greg Wooledge wrote:
On Mon, Feb 15, 2016 at 10:31:24AM -0800, LA Walsh wrote:
Ended up looking at manpage, where it says under "ENVIRONMENT":
EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug
defaults to emacs.
This is not correct (probably it used to be
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -D
I seem to remember some discussion of this before --
not being able to use -v to check if a hash was defined,
but having it "work"(?) w/arrays?
I think, though, the fact that it operates inconsistently
makes it a bug. I.e. if always work or fail, at least it
is behaving consistently, feels wrong
Chet Ramey wrote:
On 2/9/16 7:30 PM, Linda Walsh wrote:
At various times I see people contributing code to bash.
I was wondering if it might be possible to use
C++ in some patches or new files?
I'm not opposed to looking at new functionality that uses C++, but I would
p
At various times I see people contributing code to bash.
I was wondering if it might be possible to use
C++ in some patches or new files?
I know that the kernel, and the glib include files go to
extra pain to declare 'C' functions when using C++ where
those C function need to be called from C++.
Andreas Schwab wrote:
Linda Walsh writes:
You can't open a file handle on a file. The fd comes from some
OS call associating it with the file on disk (or some other connection).
You ha
Dave Rutherford wrote:
On Mon, Feb 8, 2016 at 11:34 AM, Linda Walsh <mailto:b...@tlinx.org>> wrote:
>> Why would that be more reasonable than anything else? It references a
>> path that doesn't exist.
> Um...Not exactly. As long as there's a handle ope
Under the bash-arg "--debugger" it says:
Arrange for the debugger profile to be executed before the shell
starts. Turns on extended debugging mode (see the description
of the extdebug option to the shopt builtin below).
When I think of a "profile" in bash, I think of things
like
Chet Ramey wrote:
On 2/8/16 9:59 AM, Andreas Schwab wrote:
Chet Ramey writes:
`cd ..' should fail, since the parent no longer exists, and the pathname
canonicalization should fail, since there's presumably no longer a valid
path to reach the current directory. No value for $PWD is
When you are doing a var expansion using the
replacement format ${VAR//./.}, is there some way to
put parens around some part of the expression and reference
them as in the [[V~re]] RE-matches?
Couldn't find anything in the manpage, but I could easily
have missed something...?
Thanks...
Chet Ramey wrote:
On 1/12/16 4:33 PM, Linda Walsh wrote:
---
But why? It's less noisy than any alternative.
It's not as if I can type echo $(1+2) and expect it to work.
Because it only ever appeared in a Posix draft standard, and there's no
reason not to use the
Greg Wooledge wrote:
On Tue, Jan 12, 2016 at 11:52:47AM -0800, Linda Walsh wrote:
Also, from a documentation standpoint, not all behaviors are documented
in the manpage, like:
echo $[1+2]
as far as I can tell, isn't documented, yet not supporting
its behavior would break many
Chet Ramey wrote:
No. The shell doesn't perform any word expansions on the `name' when
executing a function definition command. Since the documentation doesn't
say it performs any expansions, why would you assume it does?
Because it does quote quote removal on other statements that _seem_
Andreas Schwab wrote:
That's not the same statement. The same statement would be
def='function $fn () { echo $fn ; }'
I know what you mean, but,
Yeah, sorta but I want it to do variable expansion AND quote removal.
I.e. using a var or DQ of the object-name, "a", works in declare.
Work
Reuti wrote:
Am 08.01.2016 um 21:36 schrieb Piotr Grzybowski:
hello Linda,
On Fri, Jan 8, 2016 at 9:14 PM, Linda Walsh wrote:
For what it's worth, It might be useful to have something like
'command' [..]
that would be useful, a keyword like:
function p pa
For what it's worth, It might be useful to have something like
'command' that (or maybe a flag to 'command', like "-f & -F" that would
search for functions for the 'command' either before ("-f")
the PATH search, or after ("-F"), for the case of the command not
being found in the PATH.
Reuti wro
I had an alias referring to printf that I wanted to replace
with a function.
instead of using the function declarator
'function' (or my alias 'sub'), I remembered that the official
way was to use:
P () {
...
}
But then ran into problems with the alias taking precedence over the
function.
Eduardo A. Bustamante López wrote:
This definition (
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_230
) states:
3.230 Name
In the shell command language, a word consisting solely of underscores,
digits, and alphabetics from the portable character s
Under section 2.5.3, Shell Variables, it mentions:
LC_CTYPE
Determine the interpretation of sequences of bytes of text data as
characters (for example, single-byte as opposed to multi-byte
characters), which characters are defined as letters (character class
alpha) and characters (chara
Mathieu Lirzin wrote:
Hi,
Greg Wooledge writes:
On Thu, Dec 03, 2015 at 01:08:13PM +0200, Ludovic Courtès wrote:
Given that the GCS suggests installing only the Info version of the
manual by default (info "(standards) Standard Targets")
What do you think?
I think that's a stupid suggestio
Your prompt might be too long.
Your 'dir' string is awfully long...
echo "$dir"|wc -c
270
---
I tried a shorter version on linux:
sdir='△_ >'
pre='Ishtar:/tmp/' ## prefix of my dir
Ishtar:/tmp/△>
012345678901234567890123456
-bash: 012345678901234567890123456: command no
konsolebox wrote:
On Thu, Nov 19, 2015 at 4:29 AM, Linda Walsh wrote:
However one cannot
categorically say that a NUL byte can't be used as an argument.
Likely only in an escaped format, or just as a single byte or character.
Solving
other places where it doesn't work might
Greg Wooledge wrote:
On Wed, Nov 18, 2015 at 10:46:57AM -0800, Linda Walsh wrote:
One thing that seems to be another problem. Greg called
my attention to another printf format bug:
%q causes printf to output the corresponding argument in
a
Greg Wooledge wrote:
You should stop using irrelevant examples, and return to your core
question. I believe your initial goal was to run a command, and capture
the command's stdout in one variable, and the command's stderr in another
variable, without using any temp files.
Actual
konsolebox wrote:
On Fri, Nov 13, 2015 at 8:45 AM, Linda Walsh wrote:
I'd like to be able to record stdout and stderr
without using any temp files into bash array files, AND
record the status of the command executed.
You can use coproc processes that would act as buffers.
Obvious
Greg Wooledge wrote:
On Sun, Nov 15, 2015 at 05:26:26AM -0800, Linda Walsh wrote:
This can be used to serialize an array into a file
and to read it back:
printf '%s\0' "${array[@]}" > file
So just like you can have [<>|]&[-0-9][0-0] as redire
Greg Wooledge wrote:
On Thu, Nov 12, 2015 at 04:45:49PM -0800, Linda Walsh wrote:
I'm coming up with a null-record in my brain when I think
about this: I'd like to be able to record stdout and stderr
without using any temp files into bash array files, AND
record the status of t
I'm coming up with a null-record in my brain when I think
about this: I'd like to be able to record stdout and stderr
without using any temp files into bash array files, AND
record the status of the command executed.
Something along the lines of
Array stderr=() stdout=()
runprog () {
"RUN"
Oleg Popov wrote:
$(...) is a subshell. Variables cannot be passed back from a subshell,
no matter how and where they are declared.
---
Um... oh.. in testor, still calling that way. I
missed that.
This is even more annoying for passing back results
than I thought. Grrr.
Oleg Popov wrote:
On Thu, Oct 22, 2015 at 03:01:06AM -0700, Linda Walsh wrote:
[cut]
I.e. test output was:
Case 2 got/Expected:
"222"
"1\ 222\ .3\ .4"
[cut]
You didn't initialize the array. By the time you do "parts[1]=222" it's
still empty. A
Greg Wooledge wrote:
Also I think you are completely misrepresenting the dynamic variable
scope system that bash uses. Variables are not just global or local.
There's an entire stack of them. When you reference a
variable (let's say i) inside a function, bash searches up
through the call
Greg Wooledge wrote:
On Sat, Oct 17, 2015 at 08:55:31AM -0700, Linda Walsh wrote:
If I needed a way to declare something global, yes...
But what I am wanting is a way to allow changing the defaults
of the implicit variable creation (which could still be
explicitly declared with &qu
Bob Proulx wrote:
Linda Walsh wrote:
Where does the OS claim it is a file descriptor?
---
1) in the kernel documentation:
file 'devices.txt:
/dev/fd /proc/self/fd symbolicFile descriptors
2) ls -Ll shows the type of what the symlink points to:
ls -Ll /dev/fd/
to
Here is an example of what I consider to be
strange and/or inconsistent behavior ( tests
2 & 3 fail).
test 3's failure is a real puzzler:
-
#!/bin/bash
shopt -s expand_aliases ; alias my=declare
alias array='my -a' int='my -i'
dmp () { printf "%q\n" "${*:?}" ; }
ip=10.20.30.40
array p
Greg Wooledge wrote:
--- please note locations of 'auto_local'
# at beginning
shopt -s auto_local
# Pick unbiased random number from 0 to N-1 ($1 = N)
# Returns value in variable r.
rand() {
shopt -u auto_local
local max=$((32768 / $1 * $1))
while (( (r=$RANDOM) >= max )); do :; done
Greg Wooledge wrote:
On Sat, Oct 17, 2015 at 05:43:15PM -0700, Linda Walsh wrote:
Chet Ramey wrote:
I think you're missing that process substitution is a word expansion
that is defined to expand to a filename.
-
??? I've never seen a usage where it expands to a filen
Chet Ramey wrote:
On 10/16/15 7:52 PM, Linda Walsh wrote:
As I mentioned, my initial take on implementation was
using standard pipes instead of named pipes (not having read
or perhaps having glossed over the 'named pipes' aspect).
I think you're missing that process substit
isabella parakiss wrote:
Maybe you can just use this?alias declare='declare -g'
If I needed a way to declare something global, yes...
But what I am wanting is a way to allow changing the defaults
of the implicit variable creation (which could still be
explicitly declared with
Ok, thinking this from a different way.
shopt -s implicit_vars_local
or
shopt -s localize_func_implicit_vars whatever...
Right now, in a function, you *can* use local in a function
to make a local var. Thing is, both 'declare' and 'typeset' also
make a *local* var in a function, unless the
In another note about different implementations associated
with the pattern "[read[array]] LVALUE [< $(]+ RVALUE [)]?"...
I gave a rough syntax for how I initially thought process
substitution might have been implemented before I got that
it used named pipes (like /dev/fd/99, for example).
repea
Mike Frysinger wrote:
our build environment relies heavily on bash. in our ebuild standard, we
declare the min version of bash that is supported (3.2 currently). this
way we don't have people using features found only in newer versions and
breaking on systems with older versions of bash.
-
Mike Frysinger wrote:
with bash-4.0, new compat options were introduced:
shopt -s compat32
and with bash-4.3, a variable was added:
export BASH_COMPAT=3.2
shopt -p|grep compat43
# (no output)
---
Maybe if you could check if there is a compat setti
Was just playing around seeing how the sigint
being ignored in children acted. wrote short
function: This behavior seems limited to testing
this as a foregnd function, not a shell script.
I.e, sourcing the function, then
execute the function:
lnch
function lnch {
set -o monitor # fy
Chet Ramey wrote:
On 10/12/15 7:39 PM, Linda Walsh wrote:
Does it also use a tmp file and use process-substitution, or is
that only when parens are present?
Here-documents and here-strings use temporary files and open them as
the standard input (or specified file descriptor) for the command
Chet Ramey wrote:
On 10/12/15 7:02 PM, Linda Walsh wrote:
It happens in posix mode.
---
How lame! It's a '!' in a quoted string. Another example
of posix braindeath -- how long before people realize that the
thing branded 'posix' now isn't the real posix
(Cc: Chet Ramey... forgot to send it to list...oop)
Chet Ramey wrote:
On 10/10/15 11:01 PM, Linda Walsh wrote:
a= read a <<< x;echo $?
0
declare -p a
declare -- a="x"
# the manpage claims "one line is read from [the input], and the result
# is split by words
Chet Ramey wrote:
Thanks for the report. I fixed this, and the fix is in the devel branch.
`mapfile' only takes a single variable name argument, and ignores others.
This is identical to the first example.
---
I see... but it pointed out that declare doesn't
actually die until it to
Chet Ramey wrote:
On 10/12/15 12:28 PM, Linda Walsh wrote:
Chet Ramey wrote:
On 10/11/15 1:37 AM, isabella parakiss wrote:
In posix mode, bash replaces ! in my PS1 with the history number.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03
"The
Chet Ramey wrote:
On 10/11/15 1:37 AM, isabella parakiss wrote:
In posix mode, bash replaces ! in my PS1 with the history number.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03
"The shell shall replace each instance of the character '!' in PS1 with
the
Chet Ramey wrote:
On 10/2/15 9:22 AM, Greg Wooledge wrote:
On Fri, Oct 02, 2015 at 03:53:42PM +0300, Christoph Gysin wrote:
I'm still curious as to why set -e is stripped in the first place?
Chet can give the definitive answer, but my take is that it's a huge
surprise to someone writing a fu
This was in the 2nd half of the note in the read&env+POSIX=>SEGFAULT,
but think it got missed by focus on the 1st part.
# I was doing some syntax testing and decided to try posix mode
# (as it disallows various vague or unclear constructs)
# in the working cases yielded the same results, but
# i
Geir Hauge wrote:
On Sat, Oct 10, 2015 at 08:01:05PM -0700, Linda Walsh wrote:
# this is odd: 2vars with content for 2:
unset a b
a= b= read a b <<< x y
declare -p a b
declare -- a="x"
declare -- b=""
# -- where did "y" go?
read a b <<<
Chet Ramey wrote:
On 10/10/15 4:19 PM, Linda Walsh wrote:
Chet Ramey wrote:
On 10/9/15 2:42 PM, Ian Jackson wrote:
However, it would be very easy for bash to provide an option (via `set
-o' perhaps) to disable this behaviour. That is, to allow SIGINT to
be delivered normally to
isabella parakiss wrote:
$ a= read a <<< x # this creates a variable in the current shell
$ declare -p a
declare -- a="x"
$ b= mapfile b <<< x# this doesn't
$ declare -p b
bash: declare: b: not found
Very good point... more interesting is adding posix mode
to the mix:
#
Chet Ramey wrote:
On 10/9/15 2:42 PM, Ian Jackson wrote:
However, it would be very easy for bash to provide an option (via `set
-o' perhaps) to disable this behaviour. That is, to allow SIGINT to
be delivered normally to child processes.
I'm restricting non-standard options to `shopt' to avo
I've run across several problems with how type -P returns errors.
1) if a file isn't executable, type returns it anyway in
ls -l /sbin/scat
-r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat
type -P scat
/sbin/scat
2) if a file is inaccessible, type still returns it an answer
There are several problems with how type -P returns errors.
1) if a file isn't executable, type returns it anyway in
ls -l /sbin/scat
-r--r--r-- 1 root root 245663 Nov 19 2013 /sbin/scat
type -P scat
/sbin/scat
2) if a file is inaccessible, type still returns it an answer for
Chet Ramey wrote:
I understand the problems of working with 10+ year old code that's
been patched through the roof and trying to add _anything_ to the
design. Thus the proposal of keeping the idea around if bash was
ever refactored such that implementing a change like this wouldn't be
a big de
Chet Ramey wrote:
These change the syntax of the shell in incompatible ways.
---
I think I had the feeling of ensuring compatibility as being important
and changing things in incompatible ways . "That's not easily changed w/o potential
chaos..."
The arithetic `for' command takes arithmetic
If I am using a var as an index in a for loop
as in:
for((i=0; i<10; ++i)); do : done
or 2) as an iterator as in
for i in {1..10}; do : done
**and** such usage is in a function,
the default is to promote 'i' to 'global' status,
which is usually not needed nor desired (that doesn't mean
some other problem)...
sorry for line noise.
Linda Walsh wrote:
Is it documented that ${!1} won't give you indirection
of "$1"? I guess I missed that, and sorta expected it
to do indirection the same as any other var, but doesn't
seem to work in 4.3.39.
Should it? Or why shouldn't it?
tnx...
-l
Is it documented that ${!1} won't give you indirection
of "$1"? I guess I missed that, and sorta expected it
to do indirection the same as any other var, but doesn't
seem to work in 4.3.39.
Should it? Or why shouldn't it?
tnx...
-l
Dave Rutherford wrote:
There are loadable builtins but I don't believe it is true that they
can magically self-load as you describe.
---
Magically self load? Right...
Installed by the tooth fairy no doubt?
Anything that's setup to load has to be configured by
*someone*...whether it is 'you'
Chet Ramey wrote:
The earlier spec had -e only exit a script if a *simple* (external)
command failed. It didn't include builtins nor functions.
This is not; builtins and functions are simple commands.
---
The builtins are _complex_ binary blobs that replace external commands.
Functions are
Mike Frysinger wrote:
On 18 Aug 2015 21:41, Linda Walsh wrote:
Mike Frysinger wrote:
On 18 Aug 2015 13:34, Linda Walsh wrote:
(2) it's using the nss system which lets people drop modules into the system
at anytime and change the overall lookups to use that. statically linking a
spe
Greg Wooledge wrote:
(Wow, how did we get here from "-e does not take effects in subshell"?)
---
because the POSIX spec changed and bash's handling of "-e"
changed to follow the new spec.
The earlier spec had -e only exit a script if a *simple* (external)
command failed. It didn't include
I sent this in response about 12 hours ago but haven't seen it
come though on the list, so thought I'd resend it.
Original Message
Subject: Re: remaking bash, trying static, glibc refuses static...?
Date: Wed, 19 Aug 2015 14:55:24 -0700
From: Linda Walsh <&
Mike Frysinger wrote:
On 18 Aug 2015 13:34, Linda Walsh wrote:
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim "dynamic library
support&quo
Greg Wooledge wrote:
On Tue, Aug 18, 2015 at 01:49:53PM -0700, Linda Walsh wrote:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.
When did POSIX or a
Andreas Schwab wrote:
Linda Walsh writes:
Ex: rmx -fr (alias to rm --one-file-system -fr, since rm lacks the
-x switch like 'find, cp, mv, et al.) no longer works to clean
out a directory && stay on *one* file system.
Now rm will delete things on any number of file systems, as
Eric Blake wrote:
Like it or not, it is the historical behavior standardized by POSIX.
This is not true. POSIX no longer documents historical behavior,
but now dictates new, historically-incompatible behaviors for a
variety of features in a variety of products (not just BASH).
As such,
Clark Wang wrote:
I had the same problem months ago. See Chet's answer:
http://lists.gnu.org/archive/html/bug-bash/2014-03/msg00069.html
===
Yep though I'm not sure about the reasoning in providing
different behaviors based on default-dir-expansion ==> convert
all relative paths to abso
Mike Frysinger wrote:
it is not political, nor is it related to bash at all
-mike
Then can you give any technical reason why a static
lib that uses no network services (i.e. running
on a mini-root ) couldn't be made available for
the various calls that currently claim "dynamic library
support
bash-4.3/lib/readline/complete.c:2193: warning: Using 'getpwent' in
statically linked applications requires at runtime the shared libraries
from the glibc version used for linking
Other syms: getpwnam, setpwent, endpwent.
Is providing a static lib that reads the local machine's /etc/passwd
f
yone know why path conversion was built into it?
Linda Walsh wrote:
Andreas Schwab wrote:
Linda Walsh writes:
in bash 4.3.39,
if I type a command, (like "."(source)) and a relative path
like : ../conf,
it expands the relative pathname to absolute pathnames.
Worksforme. Make
Andreas Schwab wrote:
Linda Walsh writes:
in bash 4.3.39,
if I type a command, (like "."(source)) and a relative path
like : ../conf,
it expands the relative pathname to absolute pathnames.
Worksforme. Make sure to run complete -r first.
---
You didn't say what version o
Andreas Schwab wrote:
Linda Walsh writes:
in bash 4.3.39,
if I type a command, (like "."(source)) and a relative path
like : ../conf,
it expands the relative pathname to absolute pathnames.
Worksforme. Make sure to run complete -r first.
---
Nope -- didn't change anything
in bash 4.3.39,
if I type a command, (like "."(source)) and a relative path
like : ../conf,
it expands the relative pathname to absolute pathnames.
This is bad .. since I reuse relative commands in different
absolute places.
It didn't used to do this, and it's a potential security problem,
since
Greg Wooledge wrote:
On Sun, Aug 02, 2015 at 01:30:14PM -0700, Linda Walsh wrote:
isatty () { test -c /proc/self/fd/1 ; }
This can be done portably with test -t 1 if you want the body of the
function to do what the name implies. (Testing for a character device
gives false positives if
Charles Daffern wrote:
On 02/08/15 20:30, Linda Walsh wrote:
if [[ $(printf "\n") == $'\n' ]]; then echo T; else echo F; fi
F
The command substitution operators ($(...) and `...`) strip all trailing
linefeeds. You are left with an empty string here.
The usual work
also noticed this similar strange behavior:
used 'ord'** for this test (trying to compare decimal val of chars)
isatty () { test -c /proc/self/fd/1 ; }
ord () { local nl=""; isatty && nl="\n"; printf "%d$nl" "'$1" ; }
ord "$(printf "\n")"
0
ord "$(printf "\t")"
9
ord "$(printf " ")"
32
o
printf "\n" |hexdump -C
0a
printf "%s" $'\n'|hexdump -C
0a
if [[ $(printf "\n") == $'\n' ]]; then echo T; else echo F; fi
F
just noticed the problem doesn't happen if I try to use '\t' (tab)
printf "\t" |hexdump -C
09
printf "%s" $'
I decided to give 4.3 a try again and ended up writing a 100 line script
to take the version# as input and auto-apply all the patches in the
patch dir.
ARG going down a rathole... oh well.
I think I got a build pretty much as I want it -- w/everything builtin
statically except for a few k
Chet Ramey wrote:
On 7/14/15 7:49 PM, Linda Walsh wrote:
---
Yeah, figures it would work right in the BASH dir... BUT...
Ishtar:tools/bash/bash-4.3> cd /suse132
--- both of the below print diagonally because they have no line endings.
I can't reproduce any of this on SUSE 13. W
Linda Walsh wrote:
Chet Ramey wrote:
Am still on 4.2, but in the bashdir, I get:
reset ... ^L
Erase is control-H (^H).
Kill is control-X (^X).
Ishtar:law> hhsfshsdfhl^C
Ishtar:law> bind
Ishtar:law> cd ../tools/bash/bash-4.3
Ishtar:tools/bash/bash-4.3> ls b
bash*
Chet Ramey wrote:
Am still on 4.2, but in the bashdir, I get:
reset ... ^L
Erase is control-H (^H).
Kill is control-X (^X).
Ishtar:law> hhsfshsdfhl^C
Ishtar:law> bind
Ishtar:law> cd ../tools/bash/bash-4.3
Ishtar:tools/bash/bash-4.3> ls b
bash*bashintl.h bashversion* b
When I go for auto complete now, the filenames no longer line up:
Ishtar:/suse132> ls e17-
e17-0.17.6-2.1.10.x86_64.rpm
e17-branding-openSUSE-0.1-10.1.
2.x86_64.rpm e17-branding-upstream-0.17.6-2.1.10.x86_64.rpm
e17-devel-0.1
7.6-2.1.10.x86_64.rpm e17-d
Chet Ramey wrote:
On 7/12/15 11:58 PM, Linda Walsh wrote:
set -A hash
This is an error
---
a brain-o -- at least I got the capitalized-A ;-)
(original code probably had a
hash hash
or
map hash
)
declare -A hash...
(I rarely type out the full command due to my aliases
and
1 - 100 of 611 matches
Mail list logo
