bash completion
I have a bash completion file (see below)
It works fine, but i would like add a feature => not expand the flag by
a space when it contain '='
curently when i do:
$ ldc2 -Df
ldc2 -Df=⊔
i would like:
ldc2 -Df
ldc2 -Df=
without space
tanks a lot
---
# bash completion for ldc
_ldc()
{
local cur prev opts opts_with_path
COMPREPLY=()
cur="${COMP_WORDS[COMP_CWORD]}"
prev="${COMP_WORDS[COMP_CWORD-1]}"
opts_with_path="-Dd= -Df= -Hd= -Hf= -I= -Xf= od= -of=
-profile-info-file= "
opts=" -D -Dd= -Df= -H -Hd= -Hf= -I= -J= -L= -O -O0 -O1 -O2 -O3 -O4
-O5 -X -Xf= -annotate -asm-verbose -c \
-check-printf-calls -code-model =medium -d
-d-debug= -d-version -debuglib -defaultlib \
-deps -enable-asserts -enable-boundscheck -disable-d-passes
-disable-excess-fp-precision -disable-fp-elim \
-disable-gc2stack -disable-non-leaf-fp-elim
-enable-preconditions -disable-red-zone \
-disable-simplify-drtcalls -disable-spill-fusing
-enable-contracts -enable-correct-eh-support \
-enable-fp-mad -enable-inlining -enable-invariants
-enable-load-pre -enable-no-infs-fp-math \
-enable-no-nans-fp-math -enable-postconditions -ena
-enable-unsafe-fp-math -fdata-sections \
-ffunction-sections -float-abi Generating debug information:
-g -gc -help -ignore \
-internalize-public-api-file= -internalize-public-api-list=
-jit-emit-debug -jit-enable-eh \
-join-liveintervals -limit-float-precis -linkonce-templates
-m32 -m64 -march= -mattr= -mcpu= -mtriple= \
-nested-ctx -noasm -noruntime - -nozero-initialized-in-bss
-o- -od= -of= -op -oq -output-bc -output-o \
-output- -pre-RA-sched -print-after -print-after-all
-print-before -print-before-all -print-machineinstrs \
-profile-estimator-loop-weight= -profile-info-file=
-profile-verifier-noassert \
-regalloc -rel =dynamic-no-pic -rewriter -run= -shrink-wrap
-singleobj -soft-float -spiller -st \
-stack-protector-buffer-size= -stats -tailcallopt
-time-passes -unittest -unwind-tables -v \
"
if [[ ${opts_with_path} =~ ${prev} ]] ; then
COMPREPLY=( $(compgen -f ${cur}) )
return 0
elif [[ ${cur} == -* ]] ; then
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
return 0
fi
}
complete -F _ldc ldc2
-
"-i" doesn't seem to work when switching 'to' interactive and ignores or errors any attemps
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 change variables , and then either exit the script entirely, OR continue it's execution. Obviously, when in interactive mode, it run the user's commands and then default to going back to the prompt. But if the script is invoked normally -- it would be have as a normal script with no interactivity... What I'd like to do, is something along the lines of starting 'readline' have it read in my current ENV's idea of history, (append to it), and be exactly as though it was a normal interactive shell... I tried somethind with 'read/eval', but there seems to be no way, even using read -e, to get to really use the same instance of readline as it would interactively... Maybe I'm going about this all wrong, but is this a deadend?
Re: bug? {1..3} doesnt' use IFS to separate fields
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 arrays you have the option where it does use the
IFS:
If the word is double-quoted, ${name[*]} expands to a single
word with the
value of each array member separated by the first character of
the IFS
special variable, and ${name[@]} expands each element of name to
a sep‐
arate word.
So it does say something about 'some patterns' inside brace expansion
using IFS in
this way.
So if I say <<<$(echo "${word{1..3}[*]}" ), it might be reasonable
syntax to support
such? I.e. for IFS=/, => "word1/word2/word3"
It would seem appropriate though redundant to have
<<<"$(echo "${word{1..3}suffix[@]}" ) would expand the same as
"word{1..3}"
i.e. word1 word2 work3,
I don't see the usefulness in having brace expansion's behavior changed by
IFS.
---
Do you see any usefulness in having it for array expansion?
Re: bug: return doesn't accept negative numbers
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 already an extension (POSIX does not require 'return' to support -- any more than it is required to support an argument of -1), I agree with your argument that bash would be more useful if, as an extension to POSIX, it would handle 'return -1' - in fact, that would match ksh behavior. Conversely, since portable code already can't use it, it's no skin off my back if nothing changes here. --- How about portable code using: (exit -1); return It's ugly, but would seem to be the portable/official way to do this.
Re: bug: return doesn't accept negative numbers
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. Bob
process substitution in PROMPT_COMMAND
I've recently refactored my PROMPT_COMMAND function to avoid superfluous
fork()s. In the body of the function, what was once this line:
local jobcount=$(jobs |wc -l)
is now this:
local job jobcount=0
while read job
do ((jobcount++))
done < <(jobs)
This works fine on bash 4. However, when attempting to use this on an
older bash 3.00.15(1) host, an error occurs; but only on 2nd or additional
subshells--not the first login shell!?! I.e. everything works fine, until
I run bash from bash.
bash: foo: line 39: syntax error near unexpected token `('
bash: foo: line 39: ` done <<(jobs);'
bash: error importing function definition for `foo'
Am I missing a finer point of redirection from a substituted process? Or
is something different in bash 3 that I need to work around here?
../C
Re: bug: return doesn't accept negative numbers
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 'should' is a subjective opinion that sometimes has little to do with objective reality. It is true, that when you display a signed char, non-signed- -extended, in a 16, 32 or 64 bit format, you see 255, and certainly, no one (including myself) would suggest 'sign extending' an error code, as that would make it "other than what it was". But just because it displays only as 0-255 under most circumstances is no reason for ignoring the implementation in all the main languages when the standard was written as accepting signed short integers. The same 'open group' that wrote posix wrote a C standard , and they defined it's exit val as taking a short int as well So they were inconsistent. Bash itself is inconsistent in that it accepts exit values the same as every other program, but limits return values to a particular subset.
Re: bug: return doesn't accept negative numbers
On 8/7/11 4:35 PM, Linda Walsh wrote: > --- > How about portable code using: > > (exit -1); return return $(( -1 & 255 )) -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
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 standard allows. Read the error message closely: it says `invalid option'. return doesn't accept any options, even ones that might possibly be interpreted as negative status values -- which the standard doesn't allow anyway. As Eric Blake showed, `return -- -1' works just fine, and sets $? to 255. If you don't want to type the three extra characters, use the $(( ... )) idiom I posted earlier. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: process substitution in PROMPT_COMMAND
On 8/7/11 6:00 PM, Curtis Doty wrote:
> I've recently refactored my PROMPT_COMMAND function to avoid superfluous
> fork()s. In the body of the function, what was once this line:
>
> local jobcount=$(jobs |wc -l)
>
> is now this:
>
> local job jobcount=0
> while read job
> do ((jobcount++))
> done < <(jobs)
As you suspect, the problem is with this part of the function. It doesn't
really have anything to do with PROMPT_COMMAND, though. You must be
exporting the function so your PROMPT_COMMAND will work in interactive
subshells, and the problem is there.
>
> This works fine on bash 4. However, when attempting to use this on an older
> bash 3.00.15(1) host, an error occurs; but only on 2nd or additional
> subshells--not the first login shell!?! I.e. everything works fine, until I
> run bash from bash.
>
> bash: foo: line 39: syntax error near unexpected token `('
> bash: foo: line 39: ` done <<(jobs);'
> bash: error importing function definition for `foo'
>
> Am I missing a finer point of redirection from a substituted process? Or is
> something different in bash 3 that I need to work around here?
One of the bugs fixed between bash-3.1 and bash-3.2 concerned formatting
problems with redirections and process substitution -- the construct you
used. That code is used to decompose functions to pass them through the
environment, and the incorrectly-formed function has a syntax error that
prevents it being imported by the subshell.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
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 about is fair play. You are giving it to me. Please be gracious on the receiving end of it. You do realize that you should comply with documented interfaces. Why? Because that is the way the interface specification is documented. If you want things to work easily then most generally the easiest way is to follow the documented practice. Unless you have an exceptional reason for doing something different from the documented interface then actively doing anything else is actively trying to be broken. > It is true, that when you display a signed char, non-signed- > -extended, in a 16, 32 or 64 bit format, you see 255, and certainly, no > one (including myself) would suggest 'sign extending' an error code, as that > would make it "other than what it was". But just because it displays > only as 0-255 under most circumstances is no reason for ignoring the > implementation in all the main languages when the standard was written > as accepting signed short integers. You appear to be confusing programming subroutine return values with program exit values. Those are two completely different things. I agree they are related concepts. We often try to force fit one into the other. But just the same they are different things. In the imortal words of Dr. Egon Spengler, "Don't cross the streams." On the topic of exit values... Back in the original V7 Unix the exit(2) call was documented simply as: The low-order 8 bits of status are available to the parent process. And that is all that it said. And the code was written in assembly without reference to whether it should be signed or not. The oldest BSD version of the sources I have access to was a little more helpful and said: The low-order 8 bits of status are available to the parent process. (Therefore status should be in the range 0 - 255) Since V7 dates to 1979 and the BSD version I looked at dates at least to from that same era it has been this way for a very long time. I grep'd through the V7 sources and found not one instance where a negative value was returned. (However there are some instances where no value was specified and the accumulator value was returned.) > The same 'open group' that wrote posix wrote a C standard , and they > defined it's exit val as taking a short int as well So they were > inconsistent. People sometimes read the POSIX standard today and think it is a design document. Let me correct that misunderstanding. It is not. POSIX is an operating system non-proliferation treaty. At the time it was created there were different and divergent systems that was making it impossible to write code for one system that would work on another system. They were all Unix systems. But they weren't the same Unix system. Code from one system would break on another system. What started out as small variances created very large problems. People found it very difficult to write portable code because these differences were getting out of hand. POSIX was intended to document the existing behavior so that if you followed the specification then you would have some hope of being able to run successfully on multiple systems. And it was intended to curb the differences from becoming greater than they were already. It tries to reign in the divergent behaviors so that there won't be more differences than already exist. This is what POSIX says about it: void exit(int status); The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any other value, though only the least significant 8 bits (that is, status & 0377) shall be available to a waiting parent process. It says that because that was the existing practice common to all Unix systems at the time. (My understanding is that VMS uses a different exit status convention. And so that is the reason for using the EXIT_SUCCESS and EXIT_FAILURE macros so that the same source could compile on VMS and still function correctly there.) My finishing gratuitous comment is that unfortunately people are now in the present day using POSIX as a design document. And design by committee never produces great results. But it is what we have to work with today because there isn't any better alternative. Bob
Re: process substitution in PROMPT_COMMAND
On Sun, 7 Aug 2011, Chet Ramey wrote:
On 8/7/11 6:00 PM, Curtis Doty wrote:
local job jobcount=0
while read job
do ((jobcount++))
done < <(jobs)
As you suspect, the problem is with this part of the function. It doesn't
really have anything to do with PROMPT_COMMAND, though. You must be
exporting the function so your PROMPT_COMMAND will work in interactive
subshells, and the problem is there.
Aha, indeed I have this too:
export -f foo
Removing it and the error goes away on successive subshells. :-)
I already export PROMPT_COMMAND=foo. Maybe I don't need to try and
re-export the function every time also?
bash: foo: line 39: syntax error near unexpected token `('
bash: foo: line 39: ` done <<(jobs);'
bash: error importing function definition for `foo'
Am I missing a finer point of redirection from a substituted process? Or is
something different in bash 3 that I need to work around here?
One of the bugs fixed between bash-3.1 and bash-3.2 concerned formatting
problems with redirections and process substitution -- the construct you
used. That code is used to decompose functions to pass them through the
environment, and the incorrectly-formed function has a syntax error that
prevents it being imported by the subshell.
Chet
Thanks Chet! I'll chalk this up as an old bug already fixed.
../C
Re: process substitution in PROMPT_COMMAND
On 8/7/11 7:02 PM, Curtis Doty wrote: > On Sun, 7 Aug 2011, Chet Ramey wrote: > >> On 8/7/11 6:00 PM, Curtis Doty wrote: >>> local job jobcount=0 >>> while read job >>> do ((jobcount++)) >>> done < <(jobs) >> >> As you suspect, the problem is with this part of the function. It doesn't >> really have anything to do with PROMPT_COMMAND, though. You must be >> exporting the function so your PROMPT_COMMAND will work in interactive >> subshells, and the problem is there. > > Aha, indeed I have this too: > > export -f foo > > Removing it and the error goes away on successive subshells. :-) > > I already export PROMPT_COMMAND=foo. Maybe I don't need to try and > re-export the function every time also? Well, if the PROMPT_COMMAND is exported to a subshell, and references a command named `foo', there should be a `foo' for it to execute. If you don't export the function, it probably won't find anything. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug: return doesn't accept negative numbers
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 standard allows. Read the error message closely: it says `invalid option'. return doesn't accept any options Does 'exit' accept any options? No. It doesn't complain. I would assert, that 'return', since it accepts no options, cannot have an 'invalid option', (there are no valid options), therefore, any argument to should attempt to be parsed as a number. Else, I would ask: If -1 is an invalid option, what are valid options...well, as you said, it accepts no options, so it shouldn't be possible for it to return a "validation" on the acceptability of something as an argument -- as the option parser should never be called on it any more than it is called on exit. As a nice enhancement, you could just default to accepting any expression that returned a number (i.e. treat it as the interior of a (()), vs. requiring that one use $(((expr))) as is now acceptable, and explicitly mention that "return $status+0x80" is a bash enhancement... Of course to return -1, apparently one can also use return $(-1)...there are plenty of ways to get around it... that wasn't the point. if shouldn't be trying to parse options any more than 'exit' does. example of a valid option It's not about "getting around the bug" -- it's that it shouldn't be checking for options in the first place!
