I'm doing some research for one of my scripts and always liked the C style
ifdef inline debug statements.
The following script seems to work just fine when using the "echo" command
instead of the currently used "printf" command.
When using "printf", I get something like the following output on st
Roger writes:
> [ "${DEBUG}" -ne "0" ] && $@
Missing quotes.
[ "${DEBUG}" -ne 0 ] && "$@"
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On 08/07/2011 02:35 PM, Linda Walsh wrote:
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 --).
On Mon, Aug 8, 2011 at 3:47 AM, Roger wrote:
> I'm doing some research for one of my scripts and always liked the C style
> ifdef inline debug statements.
>
> The following script seems to work just fine when using the "echo" command
> instead of the currently used "printf" command.
>
> When using
> On Mon, Aug 08, 2011 at 08:56:36AM -0500, Dennis Williamson wrote:
>On Mon, Aug 8, 2011 at 3:47 AM, Roger wrote:
>> I'm doing some research for one of my scripts and always liked the C style
>> ifdef inline debug statements.
...
>Another way to write the _debug() function:
>
>#!/bin/bash
>debu
On 8/8/2011 1:09 PM, Roger wrote:
On Mon, Aug 08, 2011 at 08:56:36AM -0500, Dennis Williamson wrote:
On Mon, Aug 8, 2011 at 3:47 AM, Roger wrote:
I'm doing some research for one of my scripts and always liked the C style
ifdef inline debug statements.
...
Another way to write the _debug() f
> On Mon, Aug 08, 2011 at 01:20:25PM -0400, Steven W. Orr wrote:
>Two things:
>
>1. Worrying about lost cycles every time you call _debug because it checks to
>see if debug is True is pretty miserly. If you *really* have to worry about
>that kind of economics then it's questionable whether you'r
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
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's not supposed to exp
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's not suppos
On 8/8/2011 2:38 PM, Roger wrote:
On Mon, Aug 08, 2011 at 01:20:25PM -0400, Steven W. Orr wrote:
Two things:
1. Worrying about lost cycles every time you call _debug because it checks to
see if debug is True is pretty miserly. If you *really* have to worry about
that kind of economics then it
On Mon, 08 Aug 2011 12:07:21 -0700, Linda Walsh wrote:
> however, Can you explain the purpose of the "shopt option
> 'no_empty_cmd_completion'
> and if you can do that, can you explain why I shouldn't use tab as an
> indent char on an empty line...?
Short answer: if you do
foo() {
> # hit tab
On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini wrote:
> In fact, you could do the same thing with
>
> foo() { # hit tab here
>
> and I'm sure you wouldn't consider that an empty line.
I have to take that back: it looks like bash treats the above differently
depending on whether enter was pres
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 about is fair play. Yo
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'
On Mon, 8 Aug 2011 21:40:39 +0200, Davide Brini wrote:
> On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini wrote:
>
>> In fact, you could do the same thing with
>>
>> foo() { # hit tab here
>>
>> and I'm sure you wouldn't consider that an empty line.
>
> I have to take that back: it looks like
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
On Mon, 08 Aug 2011 15:56:30 -0700, Linda Walsh wrote:
> 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
> 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."
>
>While true, it may too likel
> On Mon, Aug 08, 2011 at 03:07:15PM -0400, Steven W. Orr wrote:
>
>I didn't mean to go on a rant, but this list here should not be another place
>that discourages people from learning more of the language elements that allow
>us to do better work. Obscure features are in the mind of the uneducat
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 the same sort of
> extension. The fact that bash accepts 'exit -1' and 'exit -- -1', but only
> 'return -- -1', is the real point that
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 the same sort of
> > extension. The fact that bash accepts 'exit -1' and 'ex
Has anyone ever come across an equivalent to Linux's readlink -f that
is implemented purely in bash?
(I need readlink's function on AIX where it doesn't seem to be available).
jon.
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 contain '='
> curently when i do:
> $ ldc2 -Df
> ldc2 -Df=⊔
> i would like:
> ldc2 -Df
> ldc2 -Df=
>
> w
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 the same sort of
>>> extension.
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!
Jon Seymour wrote:
> Has anyone ever come across an equivalent to Linux's readlink -f that
> is implemented purely in bash?
>
> (I need readlink's function on AIX where it doesn't seem to be available).
Try this:
ls -l /path/to/some/link | awk '{print$NF}'
Sure it doesn't handle whitespace in
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."
While true, it may t
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
On Tue, Aug 9, 2011 at 12:49 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> Has anyone ever come across an equivalent to Linux's readlink -f that
>> is implemented purely in bash?
>>
>> (I need readlink's function on AIX where it doesn't seem to be available).
>
> Try this:
>
> ls -l /path/to/some
Jon Seymour wrote:
> readlink -f will fully resolve links in the path itself (rather than
> link at the end of the path), which was the behaviour I needed.
Ah, yes, well, as you could tell that was just a partial solution
anyway.
> It seems cd -P does most of what I need for directories and so
>
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
On Tue, Aug 9, 2011 at 1:36 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> readlink -f will fully resolve links in the path itself (rather than
>> link at the end of the path), which was the behaviour I needed.
>
> Ah, yes, well, as you could tell that was just a partial solution
> anyway.
>
>> It
Jon Seymour wrote:
> I always use sed for this purpose, so:
>
>$(cd "$dir"; ls -l "$base" | sed "s/.*->//")
>
> But, with pathological linking structures, this isn't quite enough -
> particularly if the target of the link itself contains paths, some of
> which may contain links :-)
Agreed!
On Tue, Aug 9, 2011 at 2:14 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> I always use sed for this purpose, so:
>>
>> $(cd "$dir"; ls -l "$base" | sed "s/.*->//")
>>
>> But, with pathological linking structures, this isn't quite enough -
>> particularly if the target of the link itself contain
On Tue, Aug 9, 2011 at 2:36 PM, Jon Seymour wrote:
> On Tue, Aug 9, 2011 at 2:14 PM, Bob Proulx wrote:
>> Jon Seymour wrote:
>>> I always use sed for this purpose, so:
>>>
>>> $(cd "$dir"; ls -l "$base" | sed "s/.*->//")
>>>
>>> But, with pathological linking structures, this isn't quite enoug
Jon Seymour wrote:
> readlink_f()
> {
> local path="$1"
> test -z "$path" && echo "usage: readlink_f path" 1>&2 && exit 1;
An extra ';' there that doesn't hurt but isn't needed.
> local dir
>
> if test -L "$path"
> then
> local link=$(ls -l
On Tue, Aug 9, 2011 at 2:51 PM, Bob Proulx wrote:
> Jon Seymour wrote:
>> readlink_f()
>> {
>> local path="$1"
>> test -z "$path" && echo "usage: readlink_f path" 1>&2 && exit 1;
>
> An extra ';' there that doesn't hurt but isn't needed.
>
>> local dir
>>
>> if test
> On Mon, Aug 08, 2011 at 07:52:38PM -0700, Linda Walsh wrote:
...
> Nah, that's too much like right!
... sorry, I try. :-/
--
Roger
http://rogerx.freeshell.org/
41 matches
Mail list logo
