Re: "-" operand to "sh"

On Wed, Jun 07, 2017 at 01:52:57PM +0200, Joerg Schilling wrote: > Jilles Tjoelker wrote: > > In interactive mode, job control (-m) is enabled automatically. Some > > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow > > starting an interactive shell without

Re: rm -rf ./ ../

Date:Wed, 7 Jun 2017 20:56:17 +0100 From:Stephane CHAZELAS Message-ID: <20170607195617.gf5...@chaz.gmail.com> | I imagine that text was there for some reason. I have always thought that what was important was the "one" and that the

Re: rm -rf ./ ../

2017-06-07 12:41:31 -0400, shwares...@aol.com: > Because of the 'dot or dot-dot', not 'dot and dot-dot', I construe 'they' > as "one or the other, or both if both missing" shall not be returned. You > don't synthesize an unnamed or assigned name record for one that isn't > present, to relate

Re: rm -rf ./ ../

2017-06-07 10:58:58 -0400, shwares...@aol.com: > Applications can be written portably and are expected to take into account > a generic file operand is '.' or '..' already; readdir() may or may > not include '.' or '..' values whenever a path crosses a device mount > boundary. It may only

Re: rm -rf ./ ../

Stephane Chazelas wrote: > So pdksh/zsh globs are currently only non-compliant in that they > may not match what readdir() returns, but in anycase, > applications cannot make much assumption on whether "." or ".." > should be returned, so that compliance issue is not

Re: rm -rf ./ ../

2017-06-07 12:24:33 +0100, Geoff Clare: [...] > > Yes, it's hard to tell what behaviour one can rely on with the > > current text. Is opendir(".") required to open the current > > directory even if there's no "." entry in the current directory > > (same for "..")? Is foo/./bar required to be the

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > In interactive mode, job control (-m) is enabled automatically. Some > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow > starting an interactive shell without job control using sh +m, while > other shells, such as bash and ksh93, do

Re: rm -rf ./ ../

Stephane CHAZELAS wrote: > Yes, it's hard to tell what behaviour one can rely on with the > current text. Is opendir(".") required to open the current > directory even if there's no "." entry in the current directory > (same for "..")? Is foo/./bar required to be

Re: rm -rf ./ ../

Stephane CHAZELAS wrote, on 07 Jun 2017: > > 2017-06-07 12:41:52 +0200, Joerg Schilling: > > Stephane Chazelas wrote: > > > > > Do you have an opinion on whether POSIX should allow the > > > expansion of globs not to include "." and ".."

Re: rm -rf ./ ../

2017-06-07 12:41:52 +0200, Joerg Schilling: > Stephane Chazelas wrote: > > > Do you have an opinion on whether POSIX should allow the > > expansion of globs not to include "." and ".." by default? > > The fact that some filesystems include "." and ".." in the

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > In interactive mode, job control (-m) is enabled automatically. Some This is true for ksh, but not required by POSIX. > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow You are right for FreeBSD sh, dash and mksh, but the beirloom

Re: rm -rf ./ ../

2017-06-07 09:03:52 +0100, Geoff Clare: > Stephane Chazelas wrote, on 06 Jun 2017: [...] > > rm -rf ./ ../ > > > > AFAICT, with the above wording, that doesn't allow rm > > implementations to apply that safeguard in those cases (even > > though it's also a problem