According to the POSIX spec, using access(2) is implementation
dependent when running as superuser [1]. FreeBSD intentionally returns
true whenever euid/uid = 0 [2]. FreeBSD's /bin/sh doesn't have this
`issue' with test(1). Example:
$ ls -l typescript
-rw-r--r-- 1 gcooper gcooper 37875 Jul
On Tue, Jul 20, 2010 at 11:00 AM, Garrett Cooper wrote:
> According to the POSIX spec, using access(2) is implementation
> dependent when running as superuser [1]. FreeBSD intentionally returns
> true whenever euid/uid = 0 [2]. FreeBSD's /bin/sh doesn't have this
> `issue' with test(1). Example
On 07/20/2010 12:00 PM, Garrett Cooper wrote:
> According to the POSIX spec, using access(2) is implementation
> dependent when running as superuser [1].
But as long as the answer is correct, then the access(2) family of calls
is the right thing to use.
> FreeBSD intentionally returns
> true
On Tue, Jul 20, 2010 at 11:28 AM, Eric Blake wrote:
> On 07/20/2010 12:00 PM, Garrett Cooper wrote:
>> According to the POSIX spec, using access(2) is implementation
>> dependent when running as superuser [1].
>
> But as long as the answer is correct, then the access(2) family of calls
> is th
Ken Irving wrote:
So maybe the declaration could be fixed to show that, e.g., as either of:
name () compound-command [redirection]
function name [()] compound-command [redirection]
I can't see how to put that in one construct...
BNF would use:
< 'function' > | < '()' > [redirecti
The following function is legal syntax, but yields an error:
function good_dir [[ -n $1 && -d $1 && -r $1 && -x $1 ]]
bash: syntax error near unexpected token `[['
To which Andreas comments that it's a grammar bug:
Andreas Schwab wrote:
Bernd Eggink writes:
"If the function reserved
What are you saying it should return, because I get correct results
on linux:
sudo sh -c 'test -x start_trans; echo $?'
1
sudo bash -c 'test -x start_trans; echo $?'
1
Are you saying that access on BSD, when
passed (filename "X_OK") returns "true" for superuser even
when the file isn't execut
On Tue, Jul 20, 2010 at 2:18 PM, Linda Walsh wrote:
> What are you saying it should return, because I get correct results
> on linux:
>
> sudo sh -c 'test -x start_trans; echo $?'
> 1
> sudo bash -c 'test -x start_trans; echo $?' 1
>
> Are you saying that access on BSD, when
> passed (filename "X
On 07/20/2010 03:22 PM, Garrett Cooper wrote:
> Correct.
>
>> Sounds like a bug to me if a file isn't executable, I don't care
>> how "super" you are -- permission won't make a text file executable!
>> ;-)
>
> Yes, but POSIX says that it's allowed to be broken based on past
> behavior, and
On 7/20/10 2:00 PM, Garrett Cooper wrote:
> According to the POSIX spec, using access(2) is implementation
> dependent when running as superuser [1]. FreeBSD intentionally returns
> true whenever euid/uid = 0 [2]. FreeBSD's /bin/sh doesn't have this
> `issue' with test(1). Example:
Bash-4.1 do
On Tue, Jul 20, 2010 at 5:16 PM, Chet Ramey wrote:
> On 7/20/10 2:00 PM, Garrett Cooper wrote:
>> According to the POSIX spec, using access(2) is implementation
>> dependent when running as superuser [1]. FreeBSD intentionally returns
>> true whenever euid/uid = 0 [2]. FreeBSD's /bin/sh doesn'
> from man bash, to define a function use;
>
> "function" "name"
> OR
> "name" ()
>
> right?
>
> And Compound Commands are:
>
> ( )
>{ ; )
> (( expression ))
> [[ expression ]]
> ...et al
>
> so why do I get a syntax error for
>
> function good_dir [[ -n $1 && -d $1 && -r $1
> I see this in bash(1):
>
> SHELL GRAMMAR
> ...
> Shell Function Definitions
> ...
> [ function ] name () compound-command [redirection]
>
> and do not see the version you show without the parens.
Read the text following the definition. It says, in p
> So maybe the declaration could be fixed to show that, e.g., as either of:
>
> name () compound-command [redirection]
> function name [()] compound-command [redirection]
I think this is a great suggestion.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
14 matches
Mail list logo
