I'm having a problem, I think, due to my setting the prompt in
'root' mode, to a different color. This results in me being able to
enter only 49 characters on the input line before it wraps to the next
line.
I add an open and close sequence to the normal prompt (which has no
weird problems with
Thanks for all the great suggestions on how to do the
encoding differently -- how about ideas on the input line
length being truncated?
;-)
Andreas Schwab wrote:
Dennis Williamson writes:
_CRed='\[\033[31m\]' #Red
_CRST='\[\033[0m\]' #Reset
_CBLD='\[\033[1m\]' #Bold
_CRed="\\[$(tput s
Bob Proulx wrote:
Linda Walsh wrote:
Thanks for all the great suggestions on how to do the
encoding differently -- how about ideas on the input line
length being truncated?
You seem to have misunderstood.
---
Actually, I saw the two rewrites first as they were sent via
Personal mail and
Bob Proulx wrote:
Linda Walsh wrote:
But anyway, something else is is awry.
Now my root prompt, instead of being red, looks like:
"\[\033[1m\]\[\033[31m\]Ishtar:root#\[\033[0m\] "
;-/
That will be due to incorrect quoting. Which suggestion did you
implement? There were sever
For completeness current code (haven't fixed the DISPLAY part yet):
if [ -n "$_sh_interactive_shell" ] ; then
shopt -s cdspell checkhash checkwinsize cmdhist dotglob extglob
shopt -s histappend hostcomplete lithist
shopt -s no_empty_cmd_completion xpg_echo
# build a prompt #
Ah...Caught the addition of the _prompt var as separate.
It works now:
if [ -n "$_sh_interactive_shell" ] ; then
shopt -s cdspell checkhash checkwinsize cmdhist dotglob extglob
shopt -s histappend hostcomplete lithist
shopt -s no_empty_cmd_completion xpg_echo
# build a promp
Dennis Williamson wrote:
On Mon, Feb 14, 2011 at 12:34 PM, Linda Walsh wrote:
(My 'PUBLIC's are short for:
alias PUB_CONST="typeset -xr"
alias PUBLIC="typeset -x" � � � ##aka EXPORT
Why not just do
export _prompt_open=""
Except that it'
BTW, thanks much for an overlooked, and elegant solution!
Bob Proulx wrote:
Linda Walsh wrote:
there some easy way to tell bash either to not keep track of what
it thinks is the screen width (and just allow it to wrap, if that's
possible), or to reset bash's idea of where it think
Is it possible to have an 'Option' to make '[[' compatible
with '[', w/rt pathname expansion?
It seems counter-intuitive to have:
d="/etc/rc.d/rc5.d"
if [[ ! -e $d/S??sshd ]]; then echo "sshd not enabled"; fi
give different output than:
if [ ! -e $d/S??sshd ]; then echo "sshd not enabled";
Greg Wooledge wrote:
On Mon, Mar 28, 2011 at 10:53:21AM -0700, Linda Walsh wrote:
if [ ! -e $d/S??sshd ]; then echo "sshd not enabled"; fi
That will fail quite colorfully if the glob matches multiple files.
(Also, "$d" should be quoted.)
---
If, in 30 years of unix
Hey, if one doesn't ask...
Chet Ramey wrote:
I don't think implementing an option to disable that is a good use of
time.
Chet
I was looking @ coprocess section in the manpage where it says that:
NAME must not be supplied if command is a simple command.
For the coproc:
FH1(stdout) is put in NAME[0]
FH0(stdin) is put in NAME[1]
PID is put in NAME_PID
Questions (Seems like these should be in manpage, in this s
Chet Ramey wrote:
It was a mistake to allow such characters in function names (`unset' doesn't
work to unset them without forcing -f, for instance). We're stuck with them
for backwards compatibility, but I don't have to encourage their use.
---
Why doesn't bash create some sort of "deprecate
Chet Ramey wrote:
The default name is COPROC.
--- Hmmm that one is right there...just overlooked due to phrasing and
formatting:
This creates a coprocess named NAME. If NAME is not
supplied, the default name is COPROC. NAME must not be supplied
if command is a
It appears printf in bash doesn't support unicode
characters in a couple of ways:
1) use of of the \u and \U escape sequences
in the format string (16 and 32 bit Unicode values).
2) It doesn't handle the "%lc" conversion to print out wide
characters. To demonstrate this I created a
Pierre Gaston wrote:
On Fri, May 20, 2011 at 10:31 AM, Linda Walsh wrote:
It appears printf in bash doesn't support unicode
characters in a couple of ways:
1) use of of the \u and \U escape sequences
in the format string (16 and 32 bit Unicode values).
$ printf '%s
Andreas Schwab wrote:
Linda Walsh writes:
2) It doesn't handle the "%lc" conversion to print out wide
characters. To demonstrate this I created a wide char for a
double exclamation mark U+203C, using a=$'0x3c\0x20' and then
That's not a wide character,
12345678901234567890123456789012345678901234567890123456789012345678901234567890
Greg Wooledge wrote:
On Fri, May 20, 2011 at 12:31:31AM -0700, Linda Walsh wrote:
1) use of of the \u and \U escape sequences
in the format string (16 and 32 bit Unicode values).
This isn't e
Linda Walsh wrote:
Was trying a combo if statement with normal [[]] eval and an arith
exp.
in my ENV, (chose a number var at random), LINES=66
So:
echo "LINES=$LINES"
LINES=66
if [[ -z "" && ((LINES == 66 )) ]]; then echo foo; fi
foo
But:
if [[ -z "&
Was trying a combo if statement with normal [[]] eval and an arith
exp.
in my ENV, (chose a number var at random), LINES=66
So:
echo "LINES=$LINES"
LINES=66
if [[ -z "" && ((LINES == 66 )) ]]; then echo foo; fi
foo
But:
if [[ -z "" && ((LINES < 80 )) ]]; then echo foo; fi
(prints nothing).
Andreas Schwab wrote:
Linda Walsh writes:
if [[ -z "" && ((LINES < 80 )) ]]; then echo foo; fi
(prints nothing)
What am I missing?
"LINES" does not sort before "80".
Andreas.
But it compares == to 66?
Normally, in the shell, if you typ
pjodrr wrote:
Hello,
Am Dienstag, 15. März 2011 21:44:37 UTC+1 schrieb Chet Ramey:
The bash-4.1 solution, though it modified what the user typed, did not
result in any ambiguity. A filename was a filename, and if it contained
characters that needed to be quoted, readline did so.
I might be
Chet Ramey wrote:
so I'd expect the above to eval my shell-var, 'lines'...
AhI seeI need another set of parens!...
(ARG!!
What rule should I have remembered to 'know' that?
The rule you need is in the manual. In a conditional expression parens
only serve to override normal
I got great help in learning about how to do the perl equiv of (var1,
var2, var3)= (list) using read var1 var2 var3 <<<(list).
I use it often to get back lists of values from subroutine calls, but with
sometimes useful, and sometimes hindering fact that when I do
read var1 var2 var3 <<<$(funct
Pierre Gaston wrote:
> Since you are already using global variables, why not simply use a
> couple more for the return values?
>
---
Because a subshell cannot access the global variables of the
parent.
The only 'hack' I came up with overnight for a quick & dirty, is
to pass
Steven W. Orr wrote:
> On 7/25/2011 5:20 AM, Linda Walsh wrote:
> I highly recommend reading this, but read it *very carefully*. I have
> adopted this in my production system and it works great. The idea is to
> implement passing variables by reference and to allow the values to
tic' issues, I didn't really
say fully what I meant -- you would have to read it in context of the previous
message where the idea was to 'set' the global vars in the subshell (not
in a complex statement) (ex. A, below)
OR be able use a complex statement in place of a subshell
I know it wasn't designed this way, but it seems like it
is a bug.
If I do
read a b c <<<$(echo {1..3} ); echo "a:$a b:$b c:$c"
I get:
a:1 b:2 c:3
But If I do
export IFS=','; read a b c <<<$(echo {1..3} ); echo "a:$a b:$b c:$c"
I get:
a:1 2 3 b: c:
Why should the 2nd case return the w
Bob Proulx wrote:
> Linda Walsh wrote:
>> DJ Mills wrote:
>>>> Because a subshell cannot access the global variables of the parent.
>>> A subshell can access its parent's variables. foo=bar; ( echo "$foo" )
>>>
>>> A sub process ca
Linda Walsh wrote:
>
> Bob Proulx wrote:
>> Yes, but it is a fork(2) of the parent shell and all of the variables
>> from the parent are copied along with the fork into the child process
>> and that includes non-exported variables. Normally you would expect
>> t
Eric Blake wrote:
> On 07/25/2011 03:45 PM, Linda Walsh wrote:
>> I mistyped that but it brings me to an interesting
>> conundrum:
>>
>> GLOBAL="hi there"
>> {foo=GLOBAL echo ${!foo}; }
>
> This says:
>
> evaluate ${!foo}, and pass that ex
I'm trying to make first use of a coproc and having difficulties.
Multiple versions I've tried (so exact details like how to do
redirection in statement 10, have been varied in many non-working ways!
But showing the last version:
I could do the whole thing in perl as well.
Part of my reluctance to do that, is I wanted to learn why coproc
wasn't working, and how to make it work.
If I only use 'old skills', how will I learn anything new?
Andreas Schwab wrote:
awk would be much better suited for this task.
Andreas.
a make -j will automatically try to schedule tasks on different cpu's if
they are needed.
Perhaps your job's weren't sufficiently long, or you didn't specify the
makefile to be
done in parallel.
but try this:
for i in {0..7};do
(for ((j=0;j<10**6;++j)) {a=$j})&
done
That will run 8 loops of a
I guess I don't use negative return codes that often in shell, but
I use them as exit codes reasonably often.
'return' barfs on "return -1"...
Since return is defined to take no options, and ONLY an integer,
as the return code, it shouldn't be hard to fix.
Seem to fail on any negative number
Linda Walsh wrote:
Seem to fail on any negative number, but 'exit status' is defined
as a short int -- not an unsigned value (i.e. -1 would return 255).
Bob Proulx wrote:
Eric Blake wrote:
Linda Walsh wrote:
I guess I don't use negative return codes that often in shell,
I'm running shell script that will often run 'unattended' (batch),
however, for testing and future flexablity, I wish to add an **option**
(cmdline
arg) to, after defining the utils of the lib, enter normal interactive mode,
so the user could invoke the library calls from the cmdline, set or
Geir Hauge wrote:
2011/7/25 Linda Walsh
I know it wasn't designed this way, but it seems like it
is a bug.
The manual says nothing about brace expansion using IFS in any way, so it's
not a bug.
I didn't say the manual said that.
However, in expanding arra
Eric Blake wrote:
On 08/05/2011 05:41 PM, Linda Walsh wrote:
Seem to fail on any negative number, but 'exit status' is defined
as a short int -- not an unsigned value (i.e. -1 would return 255).
In bash, 'return -- -1' sets $? to 255 (note the --). But since that is
Bob Proulx wrote:
Linda Walsh wrote:
How about portable code using:
(exit -1); return
It's ugly, but would seem to be the portable/official way to
do this.
Exit codes should be in the range 0-255.
---
I suppose you don't realize that &#x
Chet Ramey wrote:
On 8/7/11 6:03 PM, Linda Walsh wrote:
Bash itself is inconsistent in that it accepts exit values the same as
every other
program, but limits return values to a particular subset.
Bash accepts any value you want to give to `return' and strips it to
8 bits, as the sta
I was testing functions in my shell, I would cut/paste,
thing is, with each past, I'd get my dir listed (sometimes multiple times)
on each line entered.
Now I have:
shopt:
no_empty_cmd_completion on
i.e. it's not supposed to expand an empty line
but type in
function foo {
return 1
}
When
Michael Witten wrote:
On Mon, Aug 8, 2011 at 18:44, Linda Walsh wrote:
I was testing functions in my shell, I would cut/paste,
thing is, with each past, I'd get my dir listed (sometimes multiple times)
on each line entered.
Now I have:
shopt:
no_empty_cmd_completion on
i.e. it&
Davide Brini wrote:
foo() { # hit enter here
# hit tab here
Display all 112 possibilities? (y or n)
The latter only attemps completion from names in the current directory.
---
Right. That was my issue.
My understanding is it shouldn't try to perform completion on an empty
line.
Eric Blake wrote:
(exit -1); return
That's not portable, either. exit is allowed to reject -1 as invalid.
POSIX is clear that exit and return have the same constraints - if an
argument is provided, it must be 0-255 to be portable.
However, you are on to something - since bash allows 'exi
Bob Proulx wrote:
Linda Walsh wrote:
Bob Proulx wrote:
Exit codes should be in the range 0-255.
---
I suppose you don't realize that 'should' is a subjective opinion that
sometimes has little to do with objective reality.
Sigh. Okay. Keep in mind that turn abo
Lest some think functions can replace aliases, there's a line in the manpage
that I feel needs amending. Currently it says:
"For almost every purpose, aliases are superseded by shell functions."
While true, it may too likely be read by some to mean that aliases have no
useful purpose. So I'
Michael Witten wrote:
In any case, even if `no_empty_cmd_completion' were to behave as Linda
expected, her tabs would still get eaten when pasted on the interactive
command line.
---
Which is what Linda expects...
the function definition wouldn't hold spaces or tabs or whitespace unle
Chet Ramey wrote:
Sure. It's just removing the three lines of code that were added
between bash-3.2 and bash-4.0. The question was always whether that's
the right thing to do, and whether the result will behave as Posix
requires.
That explains why I never ran into this before!
Roger wrote:
On Mon, Aug 08, 2011 at 02:28:00PM -0700, Linda Walsh wrote:
Lest some think functions can replace aliases, there's a line in the manpage
that I feel needs amending. Currently it says:
"For almost every purpose, aliases are superseded by shell functions."
Whi
Michael Witten wrote:
Reasonable? Or is someone going to tell me why blather is a
desired and wanted feature (under one standard or another! ;-))...
Reasonable, but naive.
Interactive bash can complete variable names, even when they are quoted.
---
That's cool!
I'm talking about a
I have a function that returns true/false.
during development, (and sometimes thereafter depending on the script, I
run with -eu, to make sure the script stops as soon as there is a
problem (well, to 'try' to make sure, many are caught.
But there are two instances that cause an error exit that s
Chet Ramey wrote:
On 8/8/11 11:43 PM, Linda Walsh wrote:
I have a function that returns true/false.
during development, (and sometimes thereafter depending on the script, I
run with -eu, to make sure the script stops as soon as there is a
problem (well, to 'try' to make sure, many
Chet Ramey wrote:
What am I doing wrong?
You're probably running into grep (and sort, and sed) buffering its
output. I haven't been able to figure out a way past that.
Chet
---
I did think of that...but I thought when the foreground
process closes 'input', then all of the chained ut
Linda Walsh wrote:
I did think of that...but I thought when the foreground
process closes 'input', then all of the chained utils should see 'eof', and
should then flush their output...at least that was my belief in how they
"should" be working...(sigh)...
-
Chet Ramey wrote:!
It's not attempting command completion, since it doesn't think
it's in a context where a command name is expected (the completion
line parsing is pretty ad-hoc -- it doesn't use the shell parser). It's
attempting readline's default filename completion. I'll have to see
whethe
Bob Proulx wrote:
Chet Ramey wrote:
Linda Walsh wrote:
Ideas?
You're probably running into grep (and sort, and sed) buffering its
output. I haven't been able to figure out a way past that.
This may be a good point to mention this reference:
http://www.pixelbeat.org/p
Chet Ramey wrote:
On 8/9/11 8:19 PM, Linda Walsh wrote:
Linda Walsh wrote:
I did think of that...but I thought when the foreground
process closes 'input', then all of the chained utils should see 'eof', and
should then flush their output...at least that was my belief
Chet Ramey wrote:
On 8/9/11 8:10 PM, Linda Walsh wrote:
The change to make (( honor the `errexit' option came in with bash-4.1,
part of the cleanup after the Posix changes to the specification of the
behavior of `set -e'. Most of the other changes in this area came in
wit
This may be some 'cockpit error', but this is what I'm seeing right
now and AFAICT, bash is broken.
I have this statement:
next line is line #300
have_dep -v base_mp_diff base_vg osnap_lv osnap_vg && {
nextents="$(get_nextents_for_space_on_vg_w_minfree \
Chet Ramey wrote:
Yes. It's a case of not saving and restoring enough state across
possibly-
recursive calls to the shell parser. (The assignment statement is the
key
in this case.)
> So, I compared subst.c files from bash-4.1-9 and bash-4.2-10 and was
> able
> to build a patch that it
Eric Blake wrote:
On 08/10/2011 03:59 PM, Linda Walsh wrote:
Is this a fluke, due to the above changes NOT being 4.1? Or is this
construction going to break in 4.2:
'$((( )))'
According to POSIX, this construction should be parsed as an arithmetic
substitution $(()) where the exp
Chet Ramey wrote:
Is this a fluke, due to the above changes NOT being 4.1? Or is
this construction going to break in 4.2:
'$((( )))'
What does `break' mean? It's already written in a manner more
confusing and obscure than necessary. What value do you think the
extra set of p
Chet Ramey wrote:
> If not, then wouldn't
> $((( ))) be turned into $( (( )) ), meaning the arith returns a
> status,
> and not the calculation. (I've tested this, and this is the case.
This is demonstrably false.
---
No... you've only proven that you should have a bit of 'compassion'
for
` Stephane CHAZELAS wrote:
2011-08-08, 13:55(-07), Linda Walsh:
[...]
and both 'exit' and 'return' should return error "ERANGE" if "--posix" is
set, and -1 is given. Iinvalid option doesn't make as much sense, in
this situtation, if it was -
Eric Blake wrote:
On 08/10/2011 10:39 PM, Linda Walsh wrote:
"It sounded to me like $(( )) would be translated into "$( () )",
turning off arithmetic expansion. Did I read that ___incorrectly__?
Yes, you read it incorrectly.
---
*thankyou*
POSIX is saying that _
Greg Wooledge wrote:
On Thu, Aug 11, 2011 at 11:56:10PM -0700, Linda Walsh wrote:
**Exception**
declare -i a
a=0
--
As a is declared to be an integer, it has the results evaluated
at assignment time. a=0 is an integer expression that doesn't set
$?=1
Neither should:
((a=0))
a
Greg Wooledge wrote:
On Fri, Aug 12, 2011 at 08:18:42AM -0700, Linda Walsh wrote:
> If I write a==0 on the bash command line, it will generate an error.
>
> a=0 does not. 'Bash' knows the difference between an assignment and
> a equality test in math.
imadev:~$ ((a
In my bash package:
rpm -qi bash
Name : bash Relocations: (not relocatable)
Version : 4.1 Vendor: openSUSE
Release : 20.25.1 Build Date: Sun 27 Feb 2011 05:51:30 AM PST
Install Date: Sun 22 May 2011 01:28:49 PM PDT Build Host: build31
...
in the 'bash' manpage, under the 'set' option, under
Greg Wooledge wrote:
On Fri, Aug 12, 2011 at 12:19:59PM -0700, Linda Walsh wrote:
Under -e, it would fail on the 'let' statement
This is one of the cases I mention on http://mywiki.wooledge.org/BashFAQ/105
AND there, you explain WHY this needs to be fixed.
Seems like this a bug in how 'groff' is configured to display various
characters.
Sorry the waste of space.
Linda Walsh wrote:
In my bash package:
rpm -qi bash
Name : bash Relocations: (not relocatable)
Version : 4.1 Vendor: openSUSE
Release : 20.25.1 Build Date: Sun 27 Feb
I want to have an array of 'names'.
given a name, "X", I had a prefix, _p_, so have _p_X,
I want to access / manipulate it as an array.
so given I pass in a name in a var, I have to use 'indirect' syntax:
${!name}
But that doesn't seem to play well with array syntax:
${#${!name}[*]}
bash:
` Dennis Williamson wrote:
On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
I have to use 'indirect' syntax: ${!name}
But that doesn't seem to play well with array syntax:
${#${!name}[*]}# bash: ${#${!name}[*]}: bad substitution
What syntax would
` Michael Witten wrote:
On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
${#${!name}[*]}
bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid, but you'll probably have to
construct and then eval the right code by hand:
$(eval
` Michael Witten wrote:
On Sun, Aug 14, 2011 at 04:55, Linda Walsh wrote:
` Michael Witten wrote:
On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
${#${!name}[*]}
bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid,
` Pierre Gaston wrote:
On Sun, Aug 14, 2011 at 7:51 AM, Linda Walsh wrote:
Dennis Williamson wrote:
On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
I have to use 'indirect' syntax: � � ${!name}
But that doesn't seem to play well with array syn
Re: BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
Pierre Gaston wrote:
Linda:
please show quote the section
that shows using an variable that holds the name of an array to be used
(and assigned to) else ...
The proof is in the faq, you could have found it if you were n
` Dennis Williamson wrote:
On Sun, Aug 14, 2011 at 6:31 PM, Linda Walsh wrote:
please show quote the section
that shows using an variable that holds the name of an array to be used
(and assigned to)
The FAQ covers indirect,
it covers arrays,
but I see no place where it covers
` Dennis Williamson wrote:
http://mywiki.wooledge.org/XyProblem
I suspect that you are hung up on the way to do something and have
lost sight of (or failed to tell us) what it is you're *actually*
trying to do.
If what you're trying to do requires complex data structures, you're
either doing
` Linda Walsh wrote:
The latest error I got is a a simple type -- most of them probably
are, with that many
lines of code in ~3-4 weeks, there's bound to be -- trouble is I'm
stubborn sometimes
about 'punishing myself'' when I mess up...which isn't alway
` Dennis Williamson wrote:
On
Greg already covered some important points and I'll add a few more.
*cough*
sorry, I just haven't responded ... I threw up my hands in disgust
and got too
irritated to respond, so have done other things.
As has been said before, d
` Dennis Williamson wrote:
Also, it's usually not necessary to maintain an index variable
and use shift in a while loop. Use "for arg; do" which uses an implied
$@.
I tried to implement your suggestion and quickly ran into the reasons
why I did what I did.
Using the 'for x;
Dennis Williamson wrote:
On Mon, Aug 15, 2011 at 10:19 PM, Linda Walsh wrote:
How do I determine the location of my script?
http://mywiki.wooledge.org/BashFAQ/028
??? I don't understand the need for complexity -- what I have works. Its a
few
lines@ most -- I use the sa
Ken Irving wrote:
On Mon, Aug 15, 2011 at 08:19:01PM -0700, Linda Walsh wrote:
today_snaps="$('ls' -1 ${snap_prefix} 2>/dev/null |tr "\n" " " )"
This one is so bad, I saved it for last. Ack! Pt! Wait, what? Why? What
the? Huh?
` Eric Blake wrote:
On 08/15/2011 04:40 PM, Sam Steingold wrote:
* Andreas Schwab [2011-08-15 22:04:04 +0200]:
Sam Steingold writes:
Cool. Now, what does this imply?
"For almost every purpose, shell functions are preferred over
aliases."
so, how do I write
alias a=b
as a function?
(
Greg Wooledge wrote:
[[[ yeah, am running a bit behind]...
On Mon, Aug 15, 2011 at 12:45:58AM -0700, Linda Walsh wrote:
> #!/bin/bash -exu
> +[shopt -s expand_aliases extglob]
>
> alias sub=function
> alias unless='if !'
Aliases don't even *work* in s
Pierre Gaston wrote:
On Mon, Aug 15, 2011 at 2:31 AM, Linda Walsh wrote:
Re: BashFAQ/006: http://mywiki.wooledge.org/BashFAQ/006
Pierre Gaston wrote:
Linda:
please show quote the section
that shows using an variable that holds the name of an array to be used (and
Pierre Gaston wrote:
Is this a question? or are you trying to make a point?
It is both -- a chance to find answer to a question, or make
the point that aliases in scripts have a useful purposes that
can't be replaced by function clls.
For the question (If I understand correctly):
1) Most
` Greg Wooledge wrote:
On Thu, Aug 18, 2011 at 06:02:14AM -0700, Linda Walsh wrote:
The "shopt -s expand_aliases" feature has been in bash since I first
encountered it in ~1999.
Fine. You know more bash bad practices than I do. You win.
Just because you didn'
Pierre Gaston wrote:
l understood a while ago, now I'll just stop feeding the troll.
---
You obviously feel there needs to be a right and wrong, and
if you haven't made me wrong, you've lost -- indicated by
your resorting to name calling rather than discussing issues.
Sigh.
` Greg Wooledge wrote:
On Thu, Aug 18, 2011 at 08:03:41AM -0700, Linda Walsh wrote:
4.2 introduce a new -g to declare a global variable inside a function.
Which doesn't say what it would do in situations like the above.
Then let's test:
imadev:~$ echo $BA
` Chet Ramey wrote:
On 8/18/11 9:37 AM, Greg Wooledge wrote:
The word following the redirection operator in the following descrip-
tions, unless otherwise noted, is subjected to brace expansion, tilde
expansion, parameter expansion, command substitution, arithmetic expan???
` Greg Wooledge wrote:
Now that one is suprising, as it's supposed to take the output of
the ... hmmm.yup!... that's exactly what it does.
takes the work and executes it and returns the results on stdin as
a single quoted blob of output:
> read a <<< *.txt
> echo $a
apc_c
Greg Wooledge wrote:
On Tue, Aug 16, 2011 at 03:41:19PM -0700, Linda Walsh wrote:
> Ken Irving wrote:
>> Maybe this? today_snaps=( ${snap_prefix} )
> but as you mention, that will put them into an arraysorry
> "imprecise terminology" list for me is some n
Chet Ramey wrote:
In yours, however, it is 0x65 0xcc 0x81 which is U+0065 LATIN SMALL
LETTER E followed by U+0301 COMBINING ACUTE ACCENT.
That's not valid UTF-8, since UTF-8 requires that the shortest sequence
be used to encode a character.
This is exactly true...
Valid UTF-8 is anythi
` Greg Wooledge wrote:
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
BTW, Thomas -- what is the Character that comes after 'De' in your
name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
RFC 2822 (section 2.2) says
Thomas De Contes wrote:
Le 25 août 2011 à 14:36, Greg Wooledge a écrit :
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
BTW, Thomas -- what is the Character that comes after 'De' in your
name? I read it as hex '0xc282c2' which doesn't
At the # prompt, if I type:
#
Chet Ramey wrote:
On 9/27/11 6:41 PM, Roger wrote:
Correct. After reading the entire Bash Manual page, I didn't see much mention
of documentation resources (of ERE) besides maybe something about egrep from
Bash's Manual Page or elsewhere on the web. After extensive research for
regex/regex
Clark J. Wang wrote:
On Fri, Jan 6, 2012 at 00:33, Peng Yu wrote:
But beware to clearly document these by giving working
EXAMPLE code which include these three commands (not just text
explanation without working code, by "working code" I mean code
snippet is discouraged, a complete completio
1 - 100 of 611 matches
Mail list logo
