LaTeX woes - Sympathy for the Blakeyrat



  • @Captain I can hack everything together in LaTeX. The point was "so much for separation of content and style"



  • Latex has shitty error messages. I wish a more modern replacement for Latex, I don't like wysiwyg editors.


  • Discourse touched me in a no-no place

    @fbmac said in LaTeX woes - Sympathy for the Blakeyrat:

    I wish a more modern replacement for Latex

    Kill me now…


  • kills Dumbledore

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    DocBook.org

    This is meant to be something for typesetting and layout?

    0_1463488156849_Capture.PNG

    Can't say they give me much confidence



  • @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    Yet the MS VC++ runtime does contain code to understand escaped quote characters.

    Gasp. Call the police.

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    And besides, I think it would be pretty normal if someone wants to use a quote character in a file name.

    I agree entirely. Remember, I "grew up" on Mac Classic, which allowed almost every character in file names (except control characters and colon). (The "separating a list of paths on the CLI" problem never came up, since Mac Classic had no CLI.)

    But that's not the point.

    You're in here ranting about a "it's impossible to use Windows filenames with a space!!!!!" and people rightfully said, "use a quote", to which you said, "but what about filenames with a quote!!!!!!!!!!" to which people rightfully said, "those don't exist" and now you're on to "well they should!!!!!!!!!!!!!!!"

    Well ok, they should. But that doesn't change the fact that the system, as it exists now, works fine.

    If Microsoft did allow quotes in file names, yes, they'd have to come up with some new delimiter. But since that's some weird hypothetical fairy world that doesn't exist, it's really not worth thinking about, is it?

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    So to me, it still looks like random limitations to cover up for other random limitations in unofficial 'magic' functionality.

    I'd much rather have "random limitations" in a system that fucking works than have absolutely zero limitations in a system that's a convoluted broken mess, like Unix/Linux. Where file names can contain (among other gibberish) newlines, where they have no established encoding (UTF8 isn't a spec, it's an assumption) and where you guys are so proud of how the shell does the file name expansion, but look what happens when you name a file "-rf" and think: "maybe it's not as great as I think?"


  • BINNED

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    @fbmac said in LaTeX woes - Sympathy for the Blakeyrat:

    I wish a more modern replacement for Latex

    Kill me now…

    What about markdown? 🍹



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    Well ok, they should. But that doesn't change the fact that the system, as it exists now, works fine.

    Except it doesn't. You could make the same case for spaces in Unix file names -- it should work, but it doesn't, but it's okay because it mostly works fine. Very uncharacteristic of you.

    I'd much rather have "random limitations" in a system that fucking works than have absolutely zero limitations in a system that's a convoluted broken mess, like Unix/Linux

    "Random limitations" are where the system is broken. Windows' file name handling is broken.

    Combine that with a Unix program that is broken in different ways and the result will be broken too. And it will be broken worse than either Windows or Unix.

    There are wrapper libraries for this, but I'd rather the TeX people worked on making TeX features better than trying for perfect interoperability.


  • I survived the hour long Uno hand

    @Captain So you define "working" as "the way Linux does it (all characters valid)" so Windows is broken.

    Blakey defines "working" as "The way Windows does it (limited characters but no space confusion)", so Linux is broken.



  • @Yamikuronue I get it, and they're both broken, because there shouldn't be any substantive limitations to what can go in a name. In principle, Unix is less broken, but there's still a lot of tools that barf on white space in file names. :prince-symbol:


  • kills Dumbledore

    @Captain What's broken is common tools not working with what the OS defines as a valid filename. Since Unix allows lots of characters that have very little use in filenames but cause a lot of complexity in parsing, that makes it harder for software to be non-broken.

    Spaces also cause problems but are a lot more useful than newlines or the bell character.



  • @Jaloopa Great, thanks for the "correction."



  • @fbmac said in LaTeX woes - Sympathy for the Blakeyrat:

    Latex has shitty error messages. I wish a more modern replacement for Latex, I don't like wysiwyg editors.

    Yep.

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    Kill me now…

    Imagine the horror on the face of this math professor at my university when he was told that the making of his textbook will be funded by an EU tender if he writes it in DocBook.



  • TRWTF is using a typesetting language to do word processing.

    People use LaTeX not because they want to use LaTeX -- well, programmers do, but that's only because they'd rather be writing code than a document and LaTeX supports that illusion -- but regular people only use LaTeX because a) the feature they need isn't available anywhere else (i.e., no feasible alternative), or b) they need a WordPerfect style system that exposes the markup. This is about 1% of users, tops.

    MS Word is the epitome of "good enough" software.



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    So to me, it still looks like random limitations to cover up for other random limitations in unofficial 'magic' functionality.

    I'd much rather have "random limitations" in a system that fucking works than have absolutely zero limitations in a system that's a convoluted broken mess, like Unix/Linux. Where file names can contain (among other gibberish) newlines, where they have no established encoding (UTF8 isn't a spec, it's an assumption) and where you guys are so proud of how the shell does the file name expansion, but look what happens when you name a file "-rf" and think: "maybe it's not as great as I think?"

    I've read the Unix-Haters Handbook so I know it's not perfect (and that classic Mac OS is awesome). But those are quite convoluted examples. All in all, it is much more likely that a random user wants to name a file The "scientific" method of Hubbard.txt than that a random user accidentally creates a file named -rf, but in the former case the design problem in Windows leads to much less disaster than the design problem in Unix in the latter case. The risk in terms of likeliness * impact is probably similar and in reality both are not really a big problem.

    Anyways, didn't I agree already that the developers who ported TeX to Windows should have done a better job?



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    Except it doesn't.

    Right; but not because there's anything wrong with Microsoft's design, but that the people who wrote those Latex CLI tools are fucking idiot moron dumbshits.

    No OS can do much against idiot moron dumbshits.

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    You could make the same case for spaces in Unix file names -- it should work, but it doesn't, but it's okay because it mostly works fine. Very uncharacteristic of you.

    Uh... huh?

    I don't know of spaces work fine in Linux, but I know tons of programs ported from Linux have issues with them. Which I presume means they also have issues with them in Linux.

    So I'd take issue with "mostly works fine" there. I think the only reason it "mostly works fine" is because Linux distros happened to be organized in such a way that none of the OS-provided directories have a space in the name. A.k.a. it "works fine" by accident, not by intent.

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    "Random limitations" are where the system is broken. Windows' file name handling is broken.

    So preventing a user from putting a 0x07 Bell character into a file name is broken? Or a newline?

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    There are wrapper libraries for this, but I'd rather the TeX people worked on making TeX features better than trying for perfect interoperability.

    Look at that installer pictured above. I don't think TeX people have worked on anything since 1996, the last time such a shitty piece of mega-ass would have been acceptable to ship.



  • @blakeyrat wah wah wah



  • @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    But those are quite convoluted examples.

    Trying to delete one directory and ending up with all subdirectories deleted, with no warning or way to undo, because you have a file with the perfectly valid name of "-rf"?

    No, that's shitty design.

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    All in all, it is much more likely that a random user wants to name a file The "scientific" method of Hubbard.txt than that a random user accidentally creates a file named -rf

    Possibly true, but that's hardly the point.

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    The risk in terms of likeliness * impact is probably similar and in reality both are not really a big problem.

    ONE DELETES FILES JACKASS!!!

    You could not be more wrong.

    A bug (read: design flaw or whatever phrase you want to use) that irrevocably deletes data is far and away worse than one that merely forces the user to rename the file before trying again.

    And you are a jackass for asserting otherwise.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    wah wah wah

    Wow. What an intelligent reply. Give me a few hours to unravel that one before I write a comeback-- jeez, man.



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    Look at that installer pictured above. I don't think TeX people have worked on anything since 1996, the last time such a shitty piece of mega-ass would have been acceptable to ship.

    To Christian Schenk's credit, the MiKTeX installer and tools have a native Windows GUI.
    And now he's looking into porting MiKTeX to Linux... sigh.

    And I forgot to mention that when they recommended TeX Live to me, they said "MiKTeX is maintained by one person, while TeX Live is maintained by a crew of people all over the world, so it works better" :)



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    ONE DELETES FILES JACKASS!!!

    No, it only makes the 'delete files' command not perform the weird 'this is a directory so I cannot delete it' behaviour. So no need to use caps lock and four exclamation marks.



  • @Grunnen I held down shift with my pinky.



  • I have so little sympathy for @marczellm's struggles right now...

    I'm in the middle of my own installer fuck up. This time, brought to us by Microsoft, who can't manage to make an installer for a flagship product that won't break.

    For some strange reason, Publisher 2010 decided not to run today. But that's okay, we have a subscription to Office 365, and I can upgrade to Office 2013 or Office 2016!

    Except, the Office 2010 installer refuses to un-install Office 2010. So now I get to babysit "Total Uninstall" for an hour before I can reinstall a new version. Do you want to see the steps Microsoft suggests?

    Installing Gentoo is easier! (And I have no love for that hobbyist project)

    Bear in mind I tried the Control Panel and then tried the Fix It tool. So the only option left to me is a "manual uninstall" that requires me to remove like 40 fucking registry keys.

    Fuck you too Microsoft.



  • Also, I like how the last step in an article titled "Remove or Uninstall Microsoft Office" is "reinstall Microsoft Office."



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    Also, I like how the last step in an article titled "Remove or Uninstall Microsoft Office" is "reinstall Microsoft Office."

    I've seen this work with other products. But you have to reinstall exactly the same version.


  • area_pol

    Spaces in filenames should have no effect on the program, because the program should not use the shell at all.

    It is trivial to reliably execute a program with an argument with spaces, regardless of the OS. Like this example for Python:

    import subprocess
    output = subprocess.check_output(['cat', 'file name with spaces'])
    

  • area_pol

    Or if you do not want Python, maybe C++?
    Here, cross platform solution to run a command with filenames containing spaces, complete with getting the return code and output:

    #include <string>
    #include <vector>
    #include <iostream>
    #include <Poco/Process.h>
    #include <Poco/PipeStream.h>
    
    int main() {
    	Poco::Pipe out, err;
    
    	std::vector<std::string> args{"file name with spaces", "other file"};
    	auto process = Poco::Process::launch("cat", args, 0, &out, &err);
    
    	Poco::PipeInputStream out_stream(out);
    	int return_code = process.wait();
    
    	std::cout << "return code:    " << return_code << '\n';
    
    	for(std::string out_line; std::getline(out_stream, out_line);) {
    		std::cout << out_line << '\n';
    	}
    
    	return 0;
    }
    

    So, no point blaming Linux or Windows.
    If someone has problems with paths-with-spaces, they are not using the right tools.



  • @blakeyrat

    $ rm - -rf

    Simple as that. The first dash effectively says "there are no more options, no matter what it looks like".



  • glob expansion done by the shell was a terrible idea



  • @fbmac said in LaTeX woes - Sympathy for the Blakeyrat:

    glob expansion done by the shell was a terrible idea

    Sure, let's just have every goddamn program need to handle the shell's job. It's not like implementing it in one place is any better than implementing it in 100000000 places.



  • @gordonjcp And... how many online help sources tell you to do that? If you forget the dash, how does the "rm" program remind you about it?



  • @ben_lubar libraries are a thing that exist.



  • @Salamander I suppose scripting languages aren't?



  • What point are you trying to make?
    Are you trying to say some scripting languages are so shit they can't support libraries? If that's the case, glob expansion is probably the least of your concerns.



  • @Salamander are you saying that scripting languages such as bash aren't allowed to have features, but those same features should be required to be implemented by every command author, even if it's as simple as adding an extra function call to the boilerplate?



  • When said feature is (for all intents and purposes) always on, introduces issues such as interpreting files as arguments, and doesn't let the app override said feature, then yes it shouldn't be there.
    It's solving a problem at the wrong level of abstraction.



  • @tufty said in LaTeX woes - Sympathy for the Blakeyrat:

    @JazzyJosh said in LaTeX woes - Sympathy for the Blakeyrat:

    TRWTF is unicode characters in directory names.
    

    TRWTF is "directory names"

    TRWTF is "directory". Just put everything in C:\ - problem with exotic characters in paths solved!



  • @Captain I always do a repair install then uninstall again if I run into these problems. But the fucking complexity of most of the Microsoft software, when most stuff just needs the files to run the app, a filetype association and shortcut to launch is nuts



  • Sad to hear that MikTex has gotten a bit retarded. Back in the day I used MikTex, with WinEdt as a frontend, for my doctoral thesis (mathematics), and it worked really well. And I could work on my thesis on my Windows box at home, then stick the latest version on floppy and take it to uni and continue working on it on the SGIs there. You can't do that with a Word document. Well, maybe you can these days—I don't know off-hand—but you couldn't back in the late 1990s.

    In fact for my earlier work—my honours thesis and some draft papers—I had been using Word. But apart from the huge filesizes produced by using the equation editor, I had a lot of issues with data corruption when going between Mac and PC versions of Word, even though the format was one they could supposedly both read.

    Using LaTeX was definitely much easier once I got used to it. I wouldn't have wanted to tackle my doctoral thesis in Word.



  • TIL tug.org is actually safe for work.


  • Discourse touched me in a no-no place

    @Salamander said in LaTeX woes - Sympathy for the Blakeyrat:

    When said feature is (for all intents and purposes) always on, introduces issues such as interpreting files as arguments, and doesn't let the app override said feature, then yes it shouldn't be there.
    It's solving a problem at the wrong level of abstraction.

    All of which would be something that I would agree with, except that I think you're getting what the abstraction should be backwards.

    The sane choices for what the arguments to a program are have to be either one string or a sequence of strings. (In theory you can use other types too, but those types are either nicely serialisable to strings, such as numbers, or are horribly complicated with internal APIs and there's no reasonable reason why one program should understand another's in this respect.) If you go with a single string, you're stuck with either just having an undifferentiated blob of characters, or putting in sub-structure to recreate some sort of sequence of things; the latter would be acceptable if everyone used the same sort of ways of indicating sub-structure to their argument string, but they don't. :(

    Using a list of values simplifies the receiving program a lot, at a cost of making the dispatching program more complex. Except that most of the time the dispatching program needs the complexity anyway (all sorts of command line shells need it because some operations are best handled internally) so there's no real advantage. Lists of strings are simpler overall, and a better technical solution.

    The only exception to this argument was with 1620-bit operating systems such as MS-DOS, where the amount of space available for passing arguments around was incredibly limited. Passing unexpanded globs around worked better in that situation. But there just was never any advantage to doing that once you've got computers with more than a few megabytes of memory; it's a hang-over from DOS and it keeps on causing low-level trouble even now.


  • Discourse touched me in a no-no place

    @Scarlet_Manuka said in LaTeX woes - Sympathy for the Blakeyrat:

    Well, maybe you can these days

    You wouldn't be working on SGI now, so technically that's a no…



  • @dkf Shame though, they were nice machines.


  • Discourse touched me in a no-no place

    @lucas1 The hardware was nice (the first systems to support showing a very large number of colours on the screen, some truly awesome supercomputers too) but the software wasn't really. I have spent rather long than I want to recall fighting with the IRIX64 build-chain, trying to get my code to build.


  • Fake News

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    @Salamander said in LaTeX woes - Sympathy for the Blakeyrat:

    When said feature is (for all intents and purposes) always on, introduces issues such as interpreting files as arguments, and doesn't let the app override said feature, then yes it shouldn't be there.
    It's solving a problem at the wrong level of abstraction.

    All of which would be something that I would agree with, except that I think you're getting what the abstraction should be backwards.

    The sane choices for what the arguments to a program are have to be either one string or a sequence of strings. (In theory you can use other types too, but those types are either nicely serialisable to strings, such as numbers, or are horribly complicated with internal APIs and there's no reasonable reason why one program should understand another's in this respect.) If you go with a single string, you're stuck with either just having an undifferentiated blob of characters, or putting in sub-structure to recreate some sort of sequence of things; the latter would be acceptable if everyone used the same sort of ways of indicating sub-structure to their argument string, but they don't. :(

    If only the OS-to-program interface were typed (like e.g. Powershell) from the beginning...

    Though likely it'd be some ancient binary structure standard.


  • Discourse touched me in a no-no place

    @JBert said in LaTeX woes - Sympathy for the Blakeyrat:

    If only the OS-to-program interface were typed (like e.g. Powershell) from the beginning...

    The problem with types is that not everything has the same types. They encode a whole bunch of assumptions, and those just aren't universal.



  • @dkf There was a bunch of SGI O2 and Octane machines that were removed in the first couple year I was at uni.

    We had some Solaris machines (Sun Ray thin terminals) with CDE (which I remember being ugly as sin, and finding some screenshots in google images my memory was correct.

    I mainly used the Solaris machines as most of my coursework was Java based.


  • Discourse touched me in a no-no place

    @lucas1 CDE wasn't the prettiest, but it worked fairly well (better than Windows of that era) provided you didn't want to actually write programs that interacted with the GUI. IRIX was prettier, but had never had a usability expert's advice applied to it; it really clunked.

    The problem with the programs that worked with CDE? It was a thin layer over Xt/Motif, and those were nasty. Even GTK is better at the programming level.


  • area_pol

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    The sane choices for what the arguments to a program are have to be either one string or a sequence of strings.

    What about using a sane syntax for that too?

    command(arg with spaces, "special, chars", keyword_arg="keyword val")
    

    And for shell-expansion:

    expand("*.txt")
    

    These things can be done well without compromising functionality. Its just how the ancient tools love to thing everything is a formless pile of bytes.


  • Discourse touched me in a no-no place

    @Adynathos said in LaTeX woes - Sympathy for the Blakeyrat:

    These things can be done well without compromising functionality.

    Spoken like someone who is used to having a spare gigabyte or two of memory for code for stuff like this. :D


  • Java Dev

    @Adynathos In bash, wildcards in double-quoted parts of the argument are not glob-expanded.


Log in to reply