This works:

cd BIN
mkdir 1
fossil uv add *
fossil uv ls

But this works not:

cd BIN
mkdir -
fossil uv add *
fossil uv ls

That directory named "-" hangs Fossil at adding uv.

Independently on is the directory empty or not.

The filename "-" is conventionally (in Unix-based programs) used as an alias for stdin or (depending on the context) stdout. What is almost certainly happening here is that fossil sees a name of "-" and is awaiting input from stdin.

FWIW, this is not a fossil-specific problem, but is a collision between common conventions and end-user practice. In short: don't use files/directories named "-". (Edit: likewise, don't use names which start with a -, as most Unix-style apps will treat those as flags unless they're prefixed with a path component.)

Note that removing or renaming such a directory will (on a Unix-like system) most likely require adding a "./" prefix to it.

rmdir ./-

or:

mv ./- foo

Edit: or apparently not - on my system rmdir and mv can handle those without a ./ prefix. Some commands cannot, though. e.g. grep treats it as an alias for stdin unless it is prefixed with a path component and (touch -) does absolutely nothing, implying that it's uselessly "touching" either stdin or stdout.

that Unix, a source of adrenalin :)

Thank you a lot!

Nonetheless, I think it's a bug 100%.

"fossil uv add" waits for input after "-" in ANY position. None behaves such way.

ALL OF

fossil uv add -
fossil uv add -- -
fossil uv add -- - qqq

HANG UP. THOUGH

fossil add -

HANGS NOT. It barks at me, sort of "not found: -" as usual.

And * expanding with "-" among other files means the same as the examples above.

What happens if you do:

echo "This is a test" | fossil uv add -

Have you trued using ./- instead? Wildcard expansion of a file named - is functionally identical to passing - on the command line, so no difference is expected.

(fossil add -) does not support reading file contents from stdin because every SCM'd file requires a name. That is apparently not the case with (fossil uv add), which internally works much differently from (fossil add).

The uv command should probably not treat - as stdin, but if it does then i have to assume that Richard had a good reasoning for allowing it.

(tap... tap tap... tap...)

The answer can be found here:

https://fossil-scm.org/fossil/help?cmd=uv

Note the --as option. The command can read from stdin and give the file a name of the user's choice.

Not a bug. It's arguably a bug that --as is not required when reading from stdin, though.

Yes, thank you, the workaround for this issue:

echo "" | fossil uv add -

really adds "-" to uv ls.

and

echo "" | fossil uv add *

really adds all of the current directory to uv ls.

But it's only a workaround, not a solution of problem.

But it's only a workaround, not a solution of problem.

My response from yesterday explains why/how this is not a bug and why/how it is a feature.

The "problem" (if it can be called that) is that you are violating Unix naming conventions which predate Ronald Regan's presidency, and then expecting tools which follow those conventions to be "fixed." As i demonstrated earlier, common tools like grep behave the same way when provided the filename -.

The "fix" here is to stop using the name - for a directory or file. Instead, use % or _, or any other character which has no de facto standard conventions commonly applied to it.

Try mkdir ~. The name ~ is magical only by long-standing convention, not by a Law of Computing or filesystem limitation. After trying that, try:

mkdir ./~
cd ~

Similarly, naming a file or directory with only whitespaces:

mkdir "    "

or, even better:

mkdir $(echo -e "\n\b")

and then try looking for that directory from the CLI, using a graphical file manager, and Midnight Commander (the results are different for each one).

Unconventional names will cause grief of some sort or other, and the fault is not with the tools - they're simply conforming to age-old conventions associated with these characters.

Having used Linux (and other Unix/POSIX systems) since I was a teen, I am certainly very familiar with - being used as a proxy for standard in.

However, does

command | fossil uv add - --as filename

really make sense in today's culture? I rarely use - to mean standard in, and have never used it with Fossil.

It might be better to make fossil uv add consistent with fossil add

~ is handled by POSIX compliant command shells (and some non-compliant shells, too). In a POSIX environment, Fossil wouldn't see it without extra effort by the user. I've never put in the effort, so I don't know if Fossil attempts to expand it.

The fact is that the current behavior allows uses which would otherwise not be possible (e.g. creating downloadable tarballs or minified JavaScript without intermediary temp files). Removing this feature would disallow such potentially useful cases while providing literally no benefit to counter that loss.

The "-" and "+" are both absolutely legal as file names. I like them. They are short and meaningful.

Again, I try these:

fossil uv add -- -

and this hangs, though I force it to look at "-" as a file name.

Then I try

fossil uv rm -

and this does not hang, though I don't force it anyhow. Why, it should behave as "uv add", not?

Then I try

fossil add -

and it works OK. The "uv add" only behaves differently, not like other fossil commands. I consider this inconsistency a bug. You may be of other opinion.

After all, there is a workaround pointed by anonymous. Thank you both for the dispute.

would disallow such potentially useful cases while providing literally no benefit to counter that loss.

I used to use - a lot. Now, with the wisdom of experience, I don't see those use cases as being particularly useful.

When I create tar/zip/whatever -balls, I always test them before "publishing" them. For that, I need the intermediary files.

Except for simple cases, having the intermediary files makes trouble-shooting much easier. (The real world always has more corner cases.)

In today's GUI world, users are used to fewer restrictions on file names than the command line world that you and I grew up in.[1]

So, which is the larger user surprise: An otherwise valid file name being rejected, or having to use intermediary files?

I think that the greater benefit for Fossil comes from having fossil uv add accept - as a file name just as fossil add does.

(Unfortunately, there are more valid file names that are a challenge for command line usage [1], but, I think, those all have to be dealt with at the command shell level, so outside of Fossil's scope.)

[1] At work, other people often send me files with & and other problem characters. For example

    `DV' Test Plan & Report.docx

Then, if I rename them and later have to send back an edited version, I get complaints that the files were renamed.

The "-" and "+" are both absolutely legal as file names. I like them. They are short and meaningful.

Again, I try these:

fossil uv add -- -

and this hangs, though I force it to look at "-" as a file name.

Then I try

fossil uv rm -

and this does not hang, though I don't force it anyhow. Why, it should behave as "uv add", not?

Then I try

fossil add -

and it works OK. The "uv add" only behaves differently, not like other fossil commands. I consider this inconsistency a bug. You may be of other opinion.

After all, there is a workaround pointed by anonymous. Thank you both for the dispute.

Actually, I meant

    echo "This is a test" | fossil uv add -

as a diagnostic, not a work around.

The work around would be to use ./- as the filename, as Stephan pointed out.

Despite using - as Stephan describes, I actually agree with you.

fossil uv add - is inconsistent with fossil add -

Not all Linux/Unix command line tools use - as a proxy for standard in.

Just as it is reasonable for fossil add - to treat - as a filename, it is equally reasonable for fossil uv add - to do so as well.

I think that not surprising new users is a greater benefit than not inconveniencing expert Linux/Unix shell programmers.

And I say that as a Linux/Unix shell programmer with many years of experience.