Dennis Williamson wrote:
read _CRST < <(tput sgr0)
instead of
_CRST=$(tput sgr0)
Run both of them with trace turned on and you'll find out.
;-)
I used to have the 2nd one...got tired of
having my tracing change colors when it got to that...
On Jun 13, 2013 4:09 PM, "Linda Walsh" wrote:
>
>
>
> Greg Wooledge wrote:
>>
>> On Thu, Jun 13, 2013 at 12:58:02PM -0700, Linda Walsh wrote:
>>>
>>> So how can my showsize function be mangling the input in a way that
>>> prevents proper execution, but isn't recorded by bash?
>>
>>
>> What makes y
Chet Ramey wrote:
Now I want to access the value for IP for the current "IF" (IF holding
eth0 or eth1 or some other InterFace name).
This is an excellent statement of the rationale for nameref variables,
which will be implemented in bash-4.3.
That order fries wouldn't happen to
Chris F.A. Johnson wrote:
On Thu, 13 Jun 2013, Linda Walsh wrote:
I have a small function in my bashrc:
function showsize () {\
local s=$(stty size); local o="(${s% *}x${s#* })"; s="${#o}";\
echo -n $o; while ((s-- > 0));do echo -ne "\b"; done; \
}
export -f showsize
trap showsize SIGWINCH
On Thu, 13 Jun 2013, Linda Walsh wrote:
I have a small function in my bashrc:
function showsize () {\
local s=$(stty size); local o="(${s% *}x${s#* })"; s="${#o}";\
echo -n $o; while ((s-- > 0));do echo -ne "\b"; done; \
}
export -f showsize
trap showsize SIGWINCH
---
That has the effect of sh
Greg Wooledge wrote:
On Thu, Jun 13, 2013 at 12:58:02PM -0700, Linda Walsh wrote:
So how can my showsize function be mangling the input in a way that
prevents proper execution, but isn't recorded by bash?
What makes you believe it's this function that's causing your problem,
and not somethin
It only happens when I alter the window size and the window
size is printed out.
Greg Wooledge wrote:
On Thu, Jun 13, 2013 at 12:58:02PM -0700, Linda Walsh wrote:
So how can my showsize function be mangling the input in a way that
prevents proper execution, but isn't recorded by bash?
What ma
On Thu, Jun 13, 2013 at 12:58:02PM -0700, Linda Walsh wrote:
> So how can my showsize function be mangling the input in a way that
> prevents proper execution, but isn't recorded by bash?
What makes you believe it's this function that's causing your problem,
and not something else, such as a PROMP
I have a small function in my bashrc:
function showsize () {\
local s=$(stty size); local o="(${s% *}x${s#* })"; s="${#o}";\
echo -n $o; while ((s-- > 0));do echo -ne "\b"; done; \
}
export -f showsize
trap showsize SIGWINCH
---
That has the effect of showing me my current window size
when I
On 06/13/2013 11:24 AM, Dan Douglas wrote:
> On Thursday, June 13, 2013 02:54:57 AM Linda Walsh wrote:
>> I can't speak to all your cases, but I had comments on a few:
>>
>> Dan Douglas wrote:
>>
>>> Most shells (and GCC) consider not grouping the assignment in a situation
>>> like this an error. B
On Thursday, June 13, 2013 02:54:57 AM Linda Walsh wrote:
> I can't speak to all your cases, but I had comments on a few:
>
> Dan Douglas wrote:
>
> > Most shells (and GCC) consider not grouping the assignment in a situation
> > like this an error. Bash tolerates it, apparently reversing associat
On 13 Jun 2013 11:00, "Linda Walsh" wrote:
> If you do it without the ':', it returns a false status.
> The colon doesn't seems to return true or false based on whether or not
> there was a syntactic error, but not for a command that runs normally and
returns
> any status.
: is just a noo
I can't speak to all your cases, but I had comments on a few:
Dan Douglas wrote:
Most shells (and GCC) consider not grouping the assignment in a situation like
this an error. Bash tolerates it, apparently reversing associativity:
: $((1 == x = 1)) # Error in dash/ksh/mksh/zsh/etc
13 matches
Mail list logo
