All,
There is a bug of some sort in bash 4.3.30 (and likely others) when
compiled with --disable-job-control on Linux/x86_64.
The following script will produce output after running for about 30 seconds:
while true; do dfOutput="$(/bin/echo test)"; if echo "${dfOutput}" |
/bin/false; then ec
On +2015/06/02 08:31:57, Greg Wooledge wrote:
>
> > Also, whatever happens, I think there should also be a way to test
> > for variable type (either another test flag or something like perl's
> > ref() ).
>
> Bash is not a strongly typed language. You've got strings, and indexed
> arrays, and a
$ echo $PATH
/usr/bin:/usr/sbin:/usr/dt/bin:/home/USER/bin
$
a truss of "bash -ls" shows it stat'ing '-bash' in each of the directories
in PATH...
11933: stat64("/usr/bin/-bash", 0xFFBFEBE8)Err#2 ENOENT
11933: stat64("/usr/sbin/-bash", 0xFFBFEBE8) Err#2 ENOENT
11933: st
On Tue, Jun 02, 2015 at 11:16:27AM -0400, Shawn Wilson wrote:
> I would argue that a nameref is a variable type.
I suppose you're right, insofar as it has its own special rules that
you have to know about.
A lot of people wanted declare -n to be more than it is. It's really
just syntactic sugar
Cygwin recently upgraded to GNU make 4.1, but in the process, it
introduced a regression in behavior on how VPATH behaves [1]. In
particular, the expression
VPATH = .:/path/to/dir
is no longer treated as a two-directory designation (search ., and if
not found then search /path/to/dir) but as a o
On Mon, Jun 01, 2015 at 09:59:51PM -0400, Shawn Wilson wrote:
> I'll preface this by saying I'm not an expert in bash by any
> means. However, most languages have a garbage collection facility
C does not. Bash (all shells, really) is very strongly influenced by C.
> and most
> high level languag
I'm surprised to read you saying that this is not a problem with Bash.
I use Bash as my shell. As configure it (from its appropriate config
file). And I get results opposite to what would be expected. And you say
there is no problem with bash? Bash does not only deal with in memory
lists because i
