Someone poked Blakey about Git again
-
@bugmenot said in Big list of software that cannot handle spaces or accents in paths:
If the only interface to your program is its CLI, then your program's human and machine interface are one and the same.
Yes, that's the problem.
-
@cheong said in Big list of software that cannot handle spaces or accents in paths:
That's why so many Windows programs need special handling when plan to support Japanese path, and that's why if your programming language have libraries supports path parsing function, you should never try to parse path yourself. :P
Yeah, and do you know why they do it wrong?
Well, it's because, in Windows's own 8-bit encodings of e.g. Japanese, that pesky backslash can appear as a non-first byte of the encoding of some non-empty subset of the set of possible "characters", so you can't just use
strchr
to find the next path separator... The WTF-16 encoding is distinctly (), as its nickname implies, but it completely avoids this particular issue. So, folks, remember to useCreateFileW
and friends, instead ofCreateFileA
! (You'll create a whole other set of bugs for yourself, of course, because of the difference between byte counts and character counts, but you can't have everything.)
-
@Yamikuronue said in Big list of software that cannot handle spaces or accents in paths:
Is this going to be one of those threads where everyone says the same thing at each other, angrily, as if to prove that they disagree?
I believe the phrase you're looking for is "violently agreeing".
-
@dkf said in Big list of software that cannot handle spaces or accents in paths:
Filenames can have newlines in.
Thanks for that. I mean the fact I knew it already was implicit in what I wrote ... but thanks anyway.
-
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
@dkf said in Big list of software that cannot handle spaces or accents in paths:
Filenames can have newlines in.
Thanks for that. I mean the fact I knew it already was implicit in what I wrote ... but thanks anyway.
You already responded to that. And I'm pretty sure @dkf just misread what you wrote.
-
@Gąska said in Big list of software that cannot handle spaces or accents in paths:
@masonwheeler said in Big list of software that cannot handle spaces or accents in paths:
I recall hearing at one point that the reason Microsoft created the "Program Files" folder as the default location for installed programs was specifically to force developers to write software that could properly handle spaces in paths.
And another team at Microsoft created a short name "PROGRA~1", which has neither spaces nor more than 8 characters.
I want to make a directory on my computer called
C:\Prograayourprogramisbadanditshouldfeelbad
-
@sloosecannon you'd need to make it before installing Windows.
-
@Magus said in Big list of software that cannot handle spaces or accents in paths:
You should at minimum have an actual API, and not be like stupid git.
Git is not a good example here. Git does have:
- actual C API here,
- distinction between ‘plumbing’ commands, intended for use in scripts, and ‘porcelain’ commands, intended for interactive use, and
- in commands that are useful both interactively and from scripts, options intended for scripts that promise not to try to be interactive.
Tools built on Git that fail due to Git trying to interact over console are pretty much always result of the tool author failing to read and understand the git documentation and not Git changing something unexpectedly.
-
@Bulb said in Big list of software that cannot handle spaces or accents in paths:
@Magus said in Big list of software that cannot handle spaces or accents in paths:
You should at minimum have an actual API, and not be like stupid git.
Git is not a good example here. Git does have:
- actual C API here,
- distinction between ‘plumbing’ commands, intended for use in scripts, and ‘porcelain’ commands, intended for interactive use, and
- in commands that are useful both interactively and from scripts, options intended for scripts that promise not to try to be interactive.
Tools built on Git that fail due to Git trying to interact over console are pretty much always result of the tool author failing to read and understand the git documentation and not Git changing something unexpectedly.
I'd observe in passing that in Real-World domestic water-management systems, the porcelain parts are installed by plumbers, just like the tube-shaped metal or plastic parts, so there's a echoing tendency to treat all those commands as if they are plumbing.
-
@Gąska said in Big list of software that cannot handle spaces or accents in paths:
@sloosecannon you'd need to make it before installing Windows.
And hope that Windows doesn't just nuke the filesystem when you do a not-upgrading install...
-
@Bulb said in Big list of software that cannot handle spaces or accents in paths:
pretty much always result of the tool author failing to read and understand the git documentation
Many problems with Git are due to people failing to understand the documentation. That's because the documentation is awful
-
@Steve_The_Cynic said in Big list of software that cannot handle spaces or accents in paths:
@Gąska said in Big list of software that cannot handle spaces or accents in paths:
@sloosecannon you'd need to make it before installing Windows.
And hope that Windows doesn't just nuke the filesystem when you do a not-upgrading install...
Alternatively, edit FAT by hand. But I don't recommend changing Program Files short name after installation.
-
@Bulb Git does not have an actual C API there. It has a C API someone wrote that calls the regular git through console commands. Because it's beyond stupid, and made by people who are beyond stupid. Oh, what's that, they're the people who designed Linux? Hmmm....
-
@Magus wait, where do you see that? The homepage says it's a pure C implementation, and the source code doesn't seem to be obviously shelling out like most of the node bindings...
-
@Yamikuronue I could be wrong, but the way that project was described to me is that since git doesn't present them with an API that's non-terminal, they have to just wrap the one available to them to give a sane API. I mean how else do you call git, unless you completely reimplement all of it?
EDIT: Wow, they really did have to reimplement it. I guess that explains why there are sometimes compatibility issues when git changes things.
-
@Magus One of the many projects on my someday list is a promise-based Node API using this instead of shell commands
-
@Yamikuronue I sure am glad Linus chooses not to expose the actual internal API for git. Isn't it wonderful that the best someone can do is:
As libgit2 is purely a consumer of the Git system, we have to adjust to changes made upstream. This has two major consequences:
- Some changes may require us to change provided interfaces. While we try to implement functions in a generic way so that no future changes are required, we cannot promise a completely stable API.
- As we have to keep up with changes in behavior made upstream, we may lag behind in some areas. We usually to document these incompatibilities in our issue tracker with the label "git change".
-
@Magus what? That looks like a result of being forced to use the actual internal API as it changes to the git developers' whims. I mean it's not like you can set up C headers and source files to only be usable by git and not libgit2. There's no way to not expose the internal API.
-
@LB_ This project exists because there is no externally accessible C API, on an app written in C. I don't know how you communicate with git in such a situation, but clearly there's a way.
-
@Magus Every C application has an "externally accessible internal API" because that's a limitation of C: There is no such thing as "private". The difference is that git's internal API isn't meant to be used or understood by outsiders and libgit2 does the work of abstracting it and making it usable and understandable. All it takes is to
#include
git's internal headers and link to the source files.
-
@LB_ So in other words, you agree that git is horribly written by people who are developer-hostile?
-
@Magus No, I'm saying that public API design is very different from internal API design.
-
@LB_ and that Git was written in a language that doesn't allow a distinction between the two?
-
@LB_ And I'm saying that if you write a source control program meant to be fast and you never make a public API, you are completely worthless as a software developer.
-
@Magus @Jaloopa I can agree with both of you. I'm honestly not sure why git's only public interface is its command line interface. I'm just saying libgit2 doesn't have to use the CLI.
-
@LB_ said in Big list of software that cannot handle spaces or accents in paths:
I'm honestly not sure why git's only public interface is its command line interface
Because Linus is a hack who doesn't understand basic software design?
-
@Jaloopa said in Big list of software that cannot handle spaces or accents in paths:
@LB_ said in Big list of software that cannot handle spaces or accents in paths:
I'm honestly not sure why git's only public interface is its command line interface
Because Linus is a hack who doesn't understand basic software design?
And yet he managed to create one of the two most commonly used operating system families around.
Just goes to show that success isn't entirely dependent on ability.
-
@LB_ So what I said, basically :)
-
@RaceProUK He has very strong skills in a specific set of areas, which have nothing to do with other developers or users.
-
@Jaloopa said in Big list of software that cannot handle spaces or accents in paths:
Because Linus is a hack who doesn't understand basic software design?
Well that's the idiot response... but no.
Git only has a CLI because the people who wrote it had no need for a GUI interface. They were unix people who ran nearly all their dev software from a command line. They weren't trying to build a company, or sell a product, or go for mass acceptance, or make my life or make your life easier.
They wanted a tool that would make their own lives easier, and would Which is exactly what they got.
It's not easy to use, because the people who wrote it wrote it for themselves, and they didn't need something that was easy to use, and didn't particularly care if it was easy to use. That's good for them, and bad for you and me. But as they don't owe us squat, why does that matter?
-
@Magus He doesn't know who the users are, he doesn't know what they want. If they are looking for software, he can tell you he doesn't have any money - but what he does have is a very particular set of skills. Skills he has acquired over a very long career. Skills that make him a nightmare for software developers like us.
-
@gwowen Everyone and their cousin has begun to use this mess as if it's the default, optimal SCM option for every situation. Some Microsoft exec even managed to get that decision across there.
The fact is, the situation has changed from back then, and to be consistently, continually hostile toward the idea of making an actual API is absolutely insane.
-
@Bulb said in Big list of software that cannot handle spaces or accents in paths:
actual C API here,
As we've had this debate like 57348467238472382387328238 times on this forum, no LibGit2 is not a C API for Git.
Git is actually designed on purpose to be difficult to create an API for. (Think of stuff like pre-commit hooks-- how do you express that in an API? Would it even be possible? Highly unlikely.) LibGit2 doesn't even slightly attempt to handle those things. So it never will, and possibly never can, be complete.
@Bulb said in Big list of software that cannot handle spaces or accents in paths:
distinction between ‘plumbing’ commands, intended for use in scripts, and ‘porcelain’ commands, intended for interactive use, and
That's not good enough.
Git was made by incompetent developers who have no clue how to make quality software. The problem they're solving with this moronic "plumbing" and "porcelain" distinction is a problem that everybody else solved 20 years ago in a far better way. There's no excuse for that. Especially not when you're a product that you're basically forcing thousands or millions of people to use. (How many people actually using Git chose Git for themselves? Percentage-wise, very few.)
@Bulb said in Big list of software that cannot handle spaces or accents in paths:
in commands that are useful both interactively and from scripts, options intended for scripts that promise not to try to be interactive.
Oh so they have a "plumbing" and "porcelain" distinction except when they don't. Great, they can't even follow their OWN moronic design.
@Bulb said in Big list of software that cannot handle spaces or accents in paths:
Tools built on Git that fail due to Git trying to interact over console are pretty much always result of the tool author failing to read and understand the git documentation and not Git changing something unexpectedly.
What about the features Git implements that it's virtually impossible for third-party tools to support at all? The fact that pre-commit hooks simply do not work on a lot of tools is, what, by design?
Oh wait, WHAT DESIGN!? The incompetent dumbshits who made Git would have had to actually have a design in the first place, and it's obvious they didn't.
Stop defending garbage software.
@Jaloopa said in Big list of software that cannot handle spaces or accents in paths:
That's because the documentation is awful
Is there anything about Git that isn't awful?
I guess it's fast-- at least until it randomly decides it needs to spend 15 minutes rebuilding your database right in the middle of a critical command.
-
@RaceProUK said in Big list of software that cannot handle spaces or accents in paths:
Just goes to show that success isn't entirely dependent on ability.
Did anybody think it was?
-
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
Well that's the idiot response... but no.
Look, if you show me Git, I say "the people who made this are no good at designing software". If you then tell me Linux Torvalds designed Git, I say "Linus Torvalds is no good at designing software".
It's like the whole Jeff Atwood thing. People thought the material he put in his blog was reasonable, until you actually see the kind of awful shitty software he builds... then it makes you go back and question everything you believed before.
The simple fact of the matter is: if your resume is Git, you're a bad software developer.
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
Git only has a CLI because the people who wrote it had no need for a GUI interface.
Oh, so they're selfish assholes! That justifies everything. Everybody loves selfish assholes.
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
They were unix people who ran nearly all their dev software from a command line.
Right, Unix people. Credo:
if you're an end user, fuck you and I want you to die
That makes me feel SO MUCH BETTER when I'm forced to use this garbage shit by an employer.
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
They weren't trying to build a company, or sell a product, or go for mass acceptance, or make my life or make your life easier.
But were they trying to make good software? Because that seems like a goal they would have had. (If so, they failed.)
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
They wanted a tool that would make their own lives easier, and would Which is exactly what they got.
Is it? Have they done studies on Git proving it? Or are they just knee-jerking?
Even if they have studied that (they haven't) and it's true (it's probably not), it certainly makes thousand of other people's lives more miserable and annoying.
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
That's good for them, and bad for you and me.
Bad software is bad for everybody. Stuff like Git why people hate computers. That's not making any of our lives easier.
Computers are for human beings.
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
But as they don't owe us squat, why does that matter?
You'd think they'd want to make a quality product if only for their own self-respect and sense of professionalism. But, oh right, open source: they have none.
-
The various third-party Bash shells for Windows:
Git Bash and MinGW Bash:
as well as MSYS2 which I have installed in D:\ProgramFiles instead of Program Files so I'm sure there was a problem.
How do you type
D:
?
-
@marczellm drag and drop the
D:
drive from Windows Explorer into the command prompt window. It will translate the path for you. The same applies to Windows Command Prompt and PowerShell.
-
@LB_ no, I mean here, so that it doesn't become a smiley!
-
@marczellm Oh, my bad. I don't know, I always wrap paths in backticks.
-
@marczellm backticks or emojis, pick your poison.
-
@LB_ said in Big list of software that cannot handle spaces or accents in paths:
Every C application has an "externally accessible internal API" because that's a limitation of C
Not actually true unless you're sticking strictly to the C Standard. Most current executable and library formats have more subtlety available.
-
@marczellm said in Big list of software that cannot handle spaces or accents in paths:
no, I mean here, so that it doesn't become a smiley!
See the source for how to do it: D:\PROGRA~1
-
@dkf said in Big list of software that cannot handle spaces or accents in paths:
See the source for how to do it: D:\PROGRA~1
Wow, D: doesn't work? That's fucking shitty.
-
@heterodox said in Big list of software that cannot handle spaces or accents in paths:
Wow, D: doesn't work? That's fucking shitty.
Sure it does! D\:
-
@dkf said in Big list of software that cannot handle spaces or accents in paths:
Sure it does! D\:
Before I read your abbr title, I figured the escaping behavior was different in an abbr, and what's worse, I wasn't even surprised.
-
@Grunnen said in Big list of software that cannot handle spaces or accents in paths:
@ben_lubar That's also find-specific.
Now try to make this work in a whitespace-proof way:
$ rm `tar -tf archive.tar`
Without testing I would expect this to work
tar --null -tf archive.tar | xargs -0 rm
-
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
Oh, so they're selfish assholes! That justifies everything. Everybody loves selfish assholes.
I make something for myself and give a copy away to you. You don't like it. Therefore I'm selfish?
You are beyond parody.
-
@blakeyrat said in Big list of software that cannot handle spaces or accents in paths:
Computers are for human beings.
Git is for human beings too. Just human beings who value different things from you in terms of what makes effective software. I use git everyday. I found it a pain in the ass at first, but now I find my workflow is incredibly easy, because I got to grips with its bizarre idiosyncracies.
You don't have to agree with them, but every now and again you may wish to consider the option that their opinions are also valid.
We now return you to your regularly schedule rage-filled solipsism.
-
@LB_ said in Big list of software that cannot handle spaces or accents in paths:
I'm honestly not sure why git's only public interface is its command line interface.
Because, as is time-honored tradition for version control systems¹, Git was implemented in shell and then gradually refactored to C. In fact, it still has some bits implemented in shell (e.g. most of the
rebase
logic). It also has bits in perl. Since the C code was written to replace bits of the shell machinery, it was written with assumption that it is executing in a separate process that will do one thing and then terminate, so error handling was done by simply terminating the process wherever the problem was detected. Such code is totally unsuitable for packing into a library. That's why most of it had to be rewritten for thelibgit2
.That said,
- separate processes have a huge advantage in that they are isolated, so their faults are isolated too,
- process can be executed from any language with similar complexity and
- since running helper processes was always the usual approach in Unix, it is optimized for it.
So it is actually good way to make API. It is just that on Windows starting processes is slow as hell and that on some (mainly mobile) systems background processes is something that is not counted with. Which means programmers are forced to reinvent fault isolation. That is ass-backwards. We already had good fault isolation using helper processes. Only if the operating systems cared to support it.
¹ CVS started that way, Arch started that way, I am pretty sure a couple more did as well.
-
@gwowen said in Big list of software that cannot handle spaces or accents in paths:
I found it a pain in the ass at first, but now I find my workflow is incredibly easy, because I got to grips with its bizarre idiosyncracies.
Is it possible to experience Stockholm syndrome with software? If so, you have it.