ken wrote:
Doing very simple math in bash fails if a number begins with a zero (0).
The short script below illustrates the problem:
---
Normally, a leading 0 begins an octal constant (I have been bitten
by this in the past as well...).
Where are you getting the value 'lastmo' from?
If from
Greg Wooledge wrote:
On Wed, Aug 26, 2009 at 02:45:39AM -0700, Linda Walsh wrote:
I had a var 'c' set to (no quotes in the var): 'C\windows\system32'
How did you assign this value? Did you read it from a file? Did you
type a specific bash command?
--
I typed it in at the prompt
Dave B wrote:
On Friday 17 July 2009, Linda Walsh wrote: (majorly abbreviated)
where output 'time' cmd go? I.e. Howto pipe_ 'time' output to _prog_ [?]
smallor filesmall?
Please see http://mywiki.wooledge.org/BashFAQ/032
An excellent and thorough webpage, but it doesn't exactly
where does the output from the 'time' command go
I.e. if I wanted to pipe the output to a prog or file, how would I
go about doing it?
Chet Ramey wrote:
Linda Walsh wrote:
When under linux (2.6.30.x), I type
ulimit -p and get a return value of 8.
from the man page this is in 512-byte blocks and may not be set.
It's set at build time. Look at builtins/ulimit.def:pipesize() and
builtins/psize.sh (which uses builtins/psize.c
When under linux (2.6.30.x), I type
ulimit -p and get a return value of 8.
from the man page this is in 512-byte blocks and may not be set.
But if I look into the linux man page:
man 7 pipe, under pipe capacity, I see:
In Linux versions before 2.6.11, the capacity of a pipe was the same as
I thought I remembered a 'bgnice' value under the 'set' or shopt
options It doesn't seem to be in my current bash. Was that
only a ksh-ism?
Maybe a feature add for bash? (also, adding a ENV var to alter the
the bg-process prio mod would be a cool addition...but no biggy either
way --
It's not a bug.
---
It's a feature... ;-)
test/[ uses -a and -o for `and' and `or'; the
conditional command uses and || for that purpose. This is
they way it's documented.
---
Would it be inappropriate if [[ were to treat -a -o identically
to -a || so [[ could be more of a
Am running an older bash version and this may be fixed (assuming it
is a bug and I'm not confused...:-))
bash version = 3.2.39(20)
This works:
1) if [ -n -a 2 -gt 1 ] ; then echo one;fi
This does not:
2) if [[ -n -a 2 -gt 1 ]] ; then echo one;fi
Shouldn't 2 work equally well
hey folks, have what is maybe, mostly a mental exercise, but...
forgive me if this is obvious, but seems I tried this before and
didn't see 'obvious' way to make this work. could be viewed as
a 'bug' (in terms of consistency' maybe?), but, I'd understand that
the design may have been limited to
Michael Potter wrote:
Bash Bunch,
Not surprisingly, bash does not exit the script when an error is detected in
a subshell.
I am hopeful that someone has a solution to this (other than: be careful to
not use subshells).
This seems to work unless I'm missing something...
#!/bin/bash
Paul Jarc wrote:
Linda Walsh [EMAIL PROTECTED] wrote:
# *1 - using -e stops your script immediately on any error
Not any error - only those from simple commands. The subtleties are
subtle enough that I avoid -e, and use between all commands
instead.
paul
Yeah...it doesn't catch
Chen(é) Jun(å) wrote:
sh -c pwd
It outputs:
/bin
Oouups, what I expect was E:/msys/1.0/bin .
Suprised? You now know what the weird sh.exe does. It checks whether some
token starts with / , if so, it considers that toke a path and applies
trasformation. This is utterly rude. So this sh.exe
Paul Jarc wrote:
It looks for substrings in both cases - specifically, the longest
matching substring, which might happen to be the entire string. With
!(), that is often the case.
x=12ab34; echo ${x//+([0-9])/X}# prints XabX
x=12ab34; echo ${x//!(+([0-9]))/X} # prints X
Stepan Koltsov wrote:
BTW, my use case for (false) is:
===
set -e
( cd some-dir make )
( cd other-dir ./build.sh )
( cd third-dir ant )
===
Most readers (and writers) expect script to fail if make failed. So
I think that outer bash should exit with error on (false) :-)
I
Paul Jarc wrote:
Linda Walsh [EMAIL PROTECTED] wrote:
In my copy of the man pages, Pattern matching is indented an extra
level making it look like it's under Pathname Expansion and only
applies there
Pattern matching applies primarily to pathname expansion; other uses
explicitly refer
Paul Jarc wrote:
Linda Walsh [EMAIL PROTECTED] wrote:
p=-e -p 60 -x
---
That's why I wanted the capture -- to pick out the 60 -- where 60 represents
a positive integer. The space between the -p and the number is optional.
It sounds like you're looking for getopt.
---
I knew about
Error invalid directory: \$1\
return $?
fi
---
Andreas Schwab wrote:
Linda Walsh [EMAIL PROTECTED] writes:
Check_file ()
{
if [[ -d $1 ]]; then echo $1 # *4
else return Error invalid directory: \$1\; fi
return expects a number, not the string
I was wondering about a possible RFE and whether or not
it is inadvisable or not. I'd be surprised if no one had
thought of it -- so maybe there is a problem in doing it.
Just like:
word#(preferred syntax)
and
word
are semantically equivalent to word 21
Has it been thought
Chet Ramey wrote:
not a standard part of the build, so it's not in the man page.
Putting a mention of it in would cause more problems that it would solve.
---
Maybe, but a mention of it might not. Some verbiage that some implementations
of bash may implement a system-wide 'bashrc'
is to screw over users who read the
man page and that bash not calling profile on non-interactive logins is
sortof (in their opinion) a bug...sigh.
Linda Walsh wrote:
*** The thing is, I'm not sure who is calling /etc/bash.bashrc.
Is it part of some standard I am not aware
Perfect! Wasn't familiar with that escape! Thanks.
-l
Mike Stroyan wrote:
Bash can know about non-printing characters. Check the PROMPTING
section in man bash-
\[ begin a sequence of non-printing characters,
which could be used to embed a terminal control sequence into the
Erp... I probably thought it was getting rid of the problem I've had
in the past with ksh-type shells of retaining a bad-mapping to a file that
was no longer accessible. A minor annoyance, admittedly, but one that
entangled me a few times several (or more) years ago...
Chet Ramey wrote:
Linda
I'm having a problem in understanding the hash command in bash:
Starting from a clean hash list, I issue a regular command and it is
then placed in the hash list (NOTE, option hashall
/ set -o|grep hash# check relevant setting
hashall on # has
Chet Ramey wrote:
You probably have the `checkhash' shell option set.
---
Yup...didn't know about that
Posix requires
that the command hash table be transparent, in the sense that it can
only be used if the hashed command corresponds to a valid pathname.
It's designed to address the
The manpages for my bash's (3.1.11 on Linux and 3.1.17 on cygwin/i686),
under Parameter Expansion, say:
${!prefix*}
[EMAIL PROTECTED]
Expands to the names of variables whose names begin with prefix,
separated by the first character of the IFS special variable.
---
From
Just started trying bashdb and noticed in the manpage that invocation
with bash --debugger has option conflict problems. If it was important
to eliminate those, there could be a special switch to indicate end of
options similar to --, meaning to pass the rest of the arguments to
a program.
IMO, common core utilities shouldn't be linking with specialized
libraries.
However, if SELinux has been adopted by Gnu.org as the standard
security mechanism, and SELinux is part of the Linux-Standard-Base
then it might not be unreasonable to include support for it.
Is SELinux part of the
501 - 528 of 528 matches
Mail list logo
