Re: doc improvement for dotglob
On Tue, Sep 27, 2016, at 11:08 AM, Chet Ramey wrote: > > Thanks for the report. There should be something in there about `.' > and `..' always having to be matched explicitly. Yw. I noticed another improvement that could be made to the docs. How do you prefer patches? And, I assume you manually deal with the duplication in different doc formats, is that right?
Re: doc improvement for dotglob
On Tue, Sep 27, 2016, at 09:41 AM, L. A. Walsh wrote: > > > Ian Kelling wrote: > > The docs currently say: > > > > "When a pattern is used for filename expansion, the character '.' at > > the start of a filename or immediately following a slash must be matched > > explicitly, unless the shell option 'dotglob' is set. > > > > The last bit should be changed to say > > > > unless the shell option 'dotglob' is set and the file is not named '.' > > or '..'. > > > --- > But that's not what is supposed to happen. It doesn't say it > matches the > filename with "." [or ".."], but the *start* of a filename or after a > "/". > I.e., interactive shell usage should not include > ".profile/.foo/.anything" in > such expansions. I'm not sure your reading it quite right. Chet gets it. Another way of explaining it is: dotglob does not affect the files "." and "..".
doc improvement for dotglob
The docs currently say: "When a pattern is used for filename expansion, the character '.' at the start of a filename or immediately following a slash must be matched explicitly, unless the shell option 'dotglob' is set. The last bit should be changed to say unless the shell option 'dotglob' is set and the file is not named '.' or '..'. And dotglob's dedicated section has similar wording to change. I looked at making a patch, but it seems the docs are repeated in many formats, so I figured I'd just post this first. -- Ian Kelling https://iankelling.org
Re: dot gob+extglob bug
The pathexp-globignore-delim.patch seems to work as advertised. > If *a matches scratch/a, for > example, that's a bug in the matching code I will have to identify and fix. Yes, this is the case. Based on your reply, the examples I showed are definitely a bug. Thank you so much.
Re: dot gob+extglob bug
Chet Ramey writes: > On 6/9/14, 3:42 PM, Ian Kelling wrote: > Yes, it's an interesting question: what exactly does pattern negation > include? You can match all filenames beginning with a `.' by using `.' > as the first character of the pattern, so should a negated pattern > beginning with a `.' match all filenames beginning with a `.' that don't > match that particular pattern? The bash-4.3 implementation says yes. > (FWIW, ksh93 disagrees.) Yes, now I understand. I agree with this bash 4.3 behavior. As you pointed out, some of my comments about past bash were wrong. Thank you. Now I think I have I have explored properly the latest version and found some problems I did not fully see before: The doc says "When matching a pathname, the slash character must always be matched explicitly." Shortly thereafter, in the next paragraph of the same section, GLOBIGNORE is described, which does not treat / as special, but this is not mentioned, and is very unexpected to me. Closer inspection, I see same language "filenames matching a pattern" is used in both paragraphs, so I think some clarification is needed. # example: / matters to GLOBIGNORE ~/opt/bash (master) $ ./bash --norc bash-4.3$ cd $(mktemp -d) bash-4.3$ touch a bash-4.3$ GLOBIGNORE=a bash-4.3$ echo * * bash-4.3$ echo ./* ./a # another example of the same phenomenon bash-4.3$ GLOBIGNORE='*a' bash-4.3$ echo ./* ./* And then, this definitely seems like a bug: * matches / in GLOGIGNORE, and so does [/], but ? does not match / # example: ? does not match "/" bash-4.3$ GLOBIGNORE=.?a bash-4.3$ echo ./* ./a # example: ? does match "x" bash-4.3$ touch .xa bash-4.3$ echo .x* .x* # example: [/] matches "/" bash-4.3$ GLOBIGNORE=.[/]a bash-4.3$ echo ./* ./.xa And then, another bug or doc clarification. The various [:class:] forms don't seem to work at all in GLOBIGNORE. Side note, I've added to my bashrc: GLOBIGNORE=*/.:*/..
dotgob+extglob bug
Running this script with your own bash path demonstrates the bug. #!/home/ian/opt/bash/bash --norc shopt -s extglob shopt -s dotglob cd $(mktemp -d) mkdir a touch a/.b touch a/c echo a/!(.b) output: a/. a/.. a/c this happens with all bash versions 4.3+ (latest is patch 18). before that, the output is: a/c Another related bug. man bash states: The file names ``.'' and ``..'' are always ignored when GLOBIGNORE is set and not null. Which clearly implies that . and .. should not be ignored in some other case. Well, that was not true before 4.3, but I'm guess this new behavior is a bug, and the doc is a bug, since the doc hasn't changed, and setting GLOBIGNORE doesn't actually make . and .. be ignored.
Re: declare a=( {1..10} )
Chet Ramey wrote: I will see whether or not I can defer brace expansion on assignment statement arguments. Chet I always remember that brace expansion happens first so I'd prefer that it expand on both kinds of assignments. I suppose it doesn't matter too much as long as its consistent. - Ian Kelling
Re: Bash 4 cursor in my prompt
Chet Ramey wrote: Ian Kelling wrote: Special Sauce wrote: From: anton To: bug-bash@gnu.org Subject: Cursor starts inside prompt I just noticed this issue too. It seems it was fine under gnu screen, but not with plain xterm or gnome-terminal. Upgrading to the latest patch version 4.0.17 fixed it. That's interesting, since none of the patches so far have dealt with readline display or prompt expansion. Odd. The earlier version does not cause it to happen now. So, I don't know what caused it. Perhaps I did something screwy in the original patch/compile sequence. - Ian Kelling
Re: Bash 4 cursor in my prompt
Chet Ramey wrote: > Ian Kelling wrote: >> Special Sauce wrote: >>> From: anton >>> To: bug-bash@gnu.org >>> Subject: Cursor starts inside prompt >> I just noticed this issue too. It seems it was fine under gnu screen, >> but not with plain xterm or gnome-terminal. Upgrading to the latest >> patch version 4.0.17 fixed it. > > That's interesting, since none of the patches so far have dealt with > readline display or prompt expansion. > > Chet > Yes, quite odd. In my initial investigation I did grep -ri "prompt" on the patches and found nothing. Some time later after a bunch of testing, I figured, well, I should upgrade from patch level 10 to 17 before reporting it, and then it was gone. If your curious or doubt this was the real issue, I could double check and narrow it down to a specific patch that fixes it. - Ian Kelling
Re: Bash 4 cursor in my prompt
Special Sauce wrote: From: anton To: bug-bash@gnu.org Subject: Cursor starts inside prompt I just noticed this issue too. It seems it was fine under gnu screen, but not with plain xterm or gnome-terminal. Upgrading to the latest patch version 4.0.17 fixed it. - Ian Kelling
Re: possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
Chet Ramey wrote: I cannot reproduce this using bash-4.0.10 or bash-4.0.17 on Mac OS X, Ubuntu, RHEL 4, or FreeBSD. Chet I can't reproduce it either. - Ian Kelling
Re: possible bash 4.0.10 bug: command substitution in PROMPT_COMMAND
Jared Yanovich wrote: Hi, I upgraded to bash 4.0.10 and my PS1 prompt is no longer displaying anything at all. I think this was addressed in a recent patch. Try upgrading to the most recent version. - Ian Kelling
Re: Bash 4 cursor in my prompt
Special Sauce wrote: [an...@nobby-nobbs ~]$ echo $PS1 [\[\e[28;1m\...@\h\[ \e[0m\]\w]$ [an...@nobby-nobbs ~]$ echo $PS2 Work fine with the bash in the ubuntu repos I put this at the end of my .bashrc and it works fine for me. PS1='[\[\e[28;1m\...@\h\[ \e[0m\]\w]$ ' Theres probably something else going on in your invocation files. Try making that the only line in your .bashrc and starting a non-login shell so thats the only file read. - Ian Kelling
Re: Bash 4 cursor in my prompt
Mike Frysinger wrote: considering it seems to involve the prompt, you really need to post your exact prompt settings (i.e. PS1/PS2/etc...) -mike Realize that in PS vars, \[ and \] should be used around non-printable characters. This surely won't happen if you start with --norc. You've got to track down everything in your invocation files that affects your prompt and narrow it down to something we can test ourselves. - Ian Kelling
Re: Creating directories with sticky bit set
Angel Tsankov wrote: > Greg Wooledge wrote: > Let's say that removing '-p' is straightforward, but what about setting the > sticky bit to every newly created directory component? > mkdir also has the -m argument, so you could do mkdir -m 1755 dir interestingly -m does not apply to parent directories created with -p If you wanted to deal with the -p, I would remove it and not pass it to mkdir, but create them yourself in the function. I'd use parameter expansion to deal with parts of the path 1 by 1. - Ian Kelling
