Bob Proulx writes:
> Same comment here about over-quoting. If nothing else it means that
> syntax highlighting is different.
>
> dir=$(cd $(dirname "$path"); pwd -P)
You are missing a pair of quotes here. :-)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerpri
On 09.08.2011 03:44, Jon Seymour wrote:
Has anyone ever come across an equivalent to Linux's readlink -f that
is implemented purely in bash?
You can find my version here:
http://sudrala.de/en_d/shell-getlink.html
As it contains some corrections from Greg Wooledge, it should handle
ev
Le mardi 09 août 2011 à 10:05 +0800, Clark J. Wang a écrit :
> On Sun, Aug 7, 2011 at 11:35 PM, jonathan MERCIER
> wrote:
> 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 contai
On 08/08/2011 08:14 PM, Chet Ramey wrote:
On 8/8/11 9:42 PM, Mike Frysinger wrote:
On Monday, August 08, 2011 21:20:29 Chet Ramey wrote:
On 8/8/11 8:53 AM, Eric Blake wrote:
However, you are on to something - since bash allows 'exit -1' as an
extension, it should similarly allow 'return -1' as
On 8/9/2011 5:29 AM, Bernd Eggink wrote:
On 09.08.2011 03:44, Jon Seymour wrote:
Has anyone ever come across an equivalent to Linux's readlink -f that
is implemented purely in bash?
You can find my version here:
http://sudrala.de/en_d/shell-getlink.html
As it contains some corrections from G
On Tue, Aug 9, 2011 at 7:29 PM, Bernd Eggink wrote:
> On 09.08.2011 03:44, Jon Seymour wrote:
>>
>> Has anyone ever come across an equivalent to Linux's readlink -f that
>> is implemented purely in bash?
>
> You can find my version here:
>
> http://sudrala.de/en_d/shell-getlink.html
>
> As
On 8/9/11 8:53 AM, Eric Blake wrote:
> On 08/08/2011 08:14 PM, Chet Ramey wrote:
>> On 8/8/11 9:42 PM, Mike Frysinger wrote:
>>> On Monday, August 08, 2011 21:20:29 Chet Ramey wrote:
On 8/8/11 8:53 AM, Eric Blake wrote:
> However, you are on to something - since bash allows 'exit -1' as an
ping,
anyone interested in reviewing/commenting on this ?
OK. I did a little tracing and found both suggestions from Mr. Williamson
and Mr. Orr very similar.
The differences, Mr. Williamson's example is more simple. Mr. Orr's example
sets the entire _debug function under another if/then statement.
The benefit I found with Mr. Orr's example, if the _d
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 are caught.
>
> But the
On 8/8/11 2:44 PM, 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's not supposed to expand an em
On 8/3/11 4:11 PM, Linda Walsh wrote:
> I've searched for coproc usage examples on the web, but there aren't
> many, and the few I found, while working for their test case, didn't
> fully replicate my setup, so it didn't work.
>
>
> Ideas?
>
>
> What am I doing wrong?
You're probably running
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 are caught.
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)...
---
Um...that got me to thin
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
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/programming/stdio_buffering/
And
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/programming/stdio_bu
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 in how they
>> "should" be working
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 in how they
"should"
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
>> with bash-4.0.
>
> I thou
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
with bash-4.0.
22 matches
Mail list logo