> I think it would be a bad idea to add a fake, bash-specific pathname > component that looks like "." and "..", which are not bash-specific.
ok, what about prefixing it with $ or any other special symbol? It can be `$...` rather than `...` . I proposed .../gradlew build but $.../gradlew build would be also acceptable. ----------- To be honest, I think I'm the only person on this planet who has ever used `...` as a file name, and nobody on this planet has never used `...` as a directory name. Finally, you can backslash special symbols and use them in file names: $ echo foo >\* $ ls \* '*' $ cat \* foo The same backslashing may work for `...` if someone ever needs three dots as a file name. ---------------- Кому: Michael Gasanenko ([email protected]); Копия: [email protected]; Тема: Three Dots: Feature Request/Philosophical Bug Report; 05.10.2025, 18:09, "Lawrence Velázquez" <[email protected]>: On Sun, Oct 5, 2025, at 3:31 AM, Michael Gasanenko wrote: **Proposal:** Let `.../` (three dots) replace any number of `../` (parent directory) symbols, provided that the file name that follows the dots exists somewhere above in the directory tree. [...] Three dots expansion MUST be performed after variable expansion but before passing paths to file I/O functions. I think it would be a bad idea to add a fake, bash-specific pathname component that looks like "." and "..", which are not bash-specific. The following doesn't work (error-checking omitted), but it would be interesting if it did: shopt -s extglob files=(*(../)foo) echo "${files[-1]}" zsh supports something similar [*]: setopt EXTENDED_GLOB echo (../)#foo(Y1) Note that we allow any file, even an ordinary file, to be mentioned between `.../` and `/..` , that is, in `.../foo/..`, `foo` need not be a directory (note that `ordinary_file/..` is not allowed in modern bash). This is not due to bash; it is a fundamental part of how pathname resolution works, even in other programs. [1]https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/base defs/V1_chap04.html#tag_04_16 I think it would be a bad idea to override the standard behavior of ".." with bash-specific behavior. Extension: `...../` (five dots) is equivalent to `../../.../` (two level-ups and three dots), e.g. `.../build.gradle/...../build.gradle` is equivalent to `.../build.gradle/../../.../build.gradle` [2]https://theonion.com/fuck-everything-were-doing-five-blades-18195 84036/ ## Appendix 2: the same functionality in Gradle/Groovy Build systems like Gragle would also benefit from both the three dots syntax and the very idea that such ancestor tree search is possible. [...] With the proposed three dots notation, it would be just: ```Groovy buildscript { dependencies{ classpath fileTree(dir: '.../anotherProject/build/libs', include: ['*.jar']) } } ``` What does this have to do with bash? Surely Groovy doesn't invoke shells to expand path strings? [*] This is a special case: Note that grouping cannot extend over multiple directories: it is an error to have a `/' within a group (this only applies for patterns used in filename generation). There is one exception: a group of the form (pat/)# appearing as a complete path segment can match a sequence of directories. For example, foo/(a*/)#bar matches foo/bar, foo/any/bar, foo/any/anyother/bar, and so on. [3]https://zsh.sourceforge.io/Doc/Release/Expansion.html#Glob-Op erators -- vq References 1. https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/basedefs/V1_chap04.html#tag_04_16 2. https://theonion.com/fuck-everything-were-doing-five-blades-1819584036/ 3. https://zsh.sourceforge.io/Doc/Release/Expansion.html#Glob-Operators
