Bash 2.05b also reproduces this problem.
On Tue, Mar 30, 2010 at 2:36 PM, Clark J. Wang wrote:
> Good news:
>
> I met this problem again a few minutes ago. Then I looked back to find out
> what I was doing. After some investigation I could stably reproduce this
> problem by following steps (test
Good news:
I met this problem again a few minutes ago. Then I looked back to find out
what I was doing. After some investigation I could stably reproduce this
problem by following steps (tested with bash 3.1.17, 3.2.39 and 4.1.0):
bash$ alias xx='echo 142857'### Make sure there isn't an exter
On 3/29/10 4:40 PM, MJ wrote:
> Hi,
>
> I was wondering if there is a way to set the color used for the
> completion listing? I would like it to stand out somewhat compared to
> my default prompt color.
There is currently no way to do that.
--
``The lyf so short, the craft so long to lerne.''
Hi,
I was wondering if there is a way to set the color used for the
completion listing? I would like it to stand out somewhat compared to
my default prompt color.
Regards,
--
MJ
On 03/29/10 11:42, Eric Blake wrote:
>>> Therefore, it is perfectly acceptable for the root user to claim that a
>>> file is executable, as reported by eaccess, even if none of the file
>>> permission bits grant such permission.
>>
>> Yes, but test should still return false if the file isn't execut
On 03/29/2010 10:36 AM, Johan Hattne wrote:
>> It also states for faccessat (eaccess is a non-portable interface
>> comparable to the standardized faccessat):
>
> But faccessat() does not really have anything to do with test?
test(1) should be implemented using faccessat(2) or equivalent, in orde
On 03/29/10 09:01, Eric Blake wrote:
> On 03/26/2010 11:47 PM, Johan Hattne wrote:
>> Description:
>> The bash built-in test command fails to correctly report executable
>> status for non-executable files when run by root on FreeBSD.
>
> Not a bug. POSIX states for test -x:
>
> True if pathn
Le 29/03/2010 14:50, Thomas Bartosik a écrit :
> Please don't get me wrong. I have no problem in understanding the
> man page this way, but I do think it is inconsistent.
It's a pity that square brackets are used both in the language itself
and in its syntactic definitions but this is bound to h
On 03/26/2010 09:59 PM, Jim Michaels wrote:
> configure is a BASH script. Am I not correct in stating that BASH requires
> BASH to install?
No. Bash requires a quasi-POSIX-conformant shell to be built, but can
be installed without the use of such a shell. Your complaint that bash
cannot be boo
On 03/26/2010 11:47 PM, Johan Hattne wrote:
> Description:
> The bash built-in test command fails to correctly report executable
> status for non-executable files when run by root on FreeBSD.
Not a bug. POSIX states for test -x:
True if pathname resolves to an existing directory entry for a
Don't get me wrong, I am a full time bash script programmer and I do know how
man pages (and their syntax) look like. I use this syntax myself in every
usage() I write...
Still I think it is misleading.
I simply cannot see how a newb can tell the difference between a bracket that's
part of the
On Mon, Mar 29, 2010 at 02:22:35PM +0200, Thomas Bartosik wrote:
> Well OK, I understand. Still I think there should be a difference in the man
> page when it comes to brackets. When talking about arrays, the brackets are
> NOT an option but mandatory.
That's correct. Referencing a specific eleme
Well OK, I understand. Still I think there should be a difference in the man
page when it comes to brackets. When talking about arrays, the brackets are NOT
an option but mandatory.
(and it might be me being uneducated, but how to you print out the decimal
equivalent of binary 11 without using b
13 matches
Mail list logo
