• lemming741@lemmy.world
    link
    fedilink
    English
    arrow-up
    145
    ·
    1 month ago

    Microsoft intentionally made programs install to C:\Program Files on Windows 95+ to force programmers to deal with spaces in filenames.

    Someone make one of those “statements made by the utterly deranged” memes about it, please and thank you.

    • Dr. Moose@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 month ago

      Hyphens > underscores for filenames because all web standards prefer hyphens so if you ever want to network your files its a much smoother experience!

      • livingcoder@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        1 month ago

        This is what I need, an explicit reason that makes one choice better than another. If hyphens make for a smoother experience, then I’ll reconsider my default behavior.

        Thanks for pointing out this benefit.

      • SaharaMaleikuhm@feddit.org
        link
        fedilink
        arrow-up
        2
        ·
        1 month ago

        They suck hard. I use the renpy engine and there you reference file names directly but always lower case and spaces and hyphens turn to underscores. That can cause issues, so I just do underscores in my file names. Don’t give damn about the web.

        • Dr. Moose@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 month ago

          Yeah I prefer underscores too but kebab case is definitely better for web and general ergonomics. Dash doesnt require a shift hold! Tho I still mix these depeding on tool or existing idioms. One thing for sure is that spaces and capital letters are stupid and we should do less of them.

    • BassTurd@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 month ago

      I prefer lowercase with hyphens, but I’m transitioning into a team that does everything camelCase, which is the second best case, but I still strongly dislike it.

  • AmazingAwesomator@lemmy.world
    link
    fedilink
    arrow-up
    14
    ·
    edit-2
    1 month ago

    i think i am old. i grew up using DOS, and really hated spaces in filenames and folders because they appreared truncated at the first space with a tilde and index of that file/folder representation.

    ex: C:\folder name is bad\ == C:\folder~1

    i hated that so much that when i got to windows 3.1 i refrained from using spaces (some command line was still necessary in w3.1)

    i have jept that habit through the years, so when i moved from windoes to linux, my natural instincts of snake_case_folder_names made it so i didnt have to change : D

    • Sonotsugipaa@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      13
      ·
      1 month ago

      They’re annoying to deal with when interactively using command-line shells, especially so when pasting unquoted and unescaped file paths, doubly especially so with Bash where parameter expansion makes no goddamn sense if you know at least one other programming language

      • ronigami@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        Example of how parameter expansion matters?

        Generally if you are pasting file paths there is a better way to do that. Use find with exec, or xargs, or a for loop. Or, get the list in Vim and escape (quote) every line at once. Unless you have double quotes in the filename too (which is actually a crazy thing) it shouldn’t be a big deal.

        • Sonotsugipaa@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 month ago

          Expansion matters because using parameters without quotes automatically splits words, and IIRC a quoted array parameter can still be split into its members — as opposed to Zsh, where word splitting doesn’t happen unprompted and quoted array parameters are flattened into a single string.

          Generally if I want to run $HOME/random executable with spaces.exe through Wine in a terminal I copy the path in Dolphin (CTRL+SHIFT+C, or CTRL+ALT+C idr) and paste it, within quotes if needed (the four extra key inputs are the annoying part).

          I find that much faster than manually typing find "$HOME" -name "random executable with spaces.exe" -type x -exec wine "{}" \;, or opening an editor to insert backslashes.

          • ronigami@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 month ago

            Why on earth not just type wine ~/random and then hit tab to autocomplete? Or you could do

            wine `echo random*`
            

            AFAIK, if $file is a filename with spaces, then some_util ${file} will not split the filename.

            • Sonotsugipaa@lemmy.dbzer0.com
              link
              fedilink
              English
              arrow-up
              3
              ·
              edit-2
              1 month ago

              If the path to the dir is longer than $HOME, say, $HOME/Tools/modding/hd2-audio-modder/wwise/v123456789_idr_but_its_a_long_one/random file name with spaces, it makes more sense.

              I’ll try using the braces syntax, if it does prevent word splitting I wasn’t aware of it, though it’s still slightly inconvenient (3 key inputs for each brace on my kb) and I’d probably still use quotes instead if I had to use Bash and had the file path in a variable for some reason.

              … though at this point I’m probably overthinking it, atm I don’t recall better examples of my distaste for Bash expansion shenanigans.


              Did some testing, here’s what I found.
              Beware, it devolves into a rant against Bash and has little to do with the original topic - I just needed to scream into the void a little.

              # Zsh
              function argn { echo $#; }
              
              var='spaced string'
              argn $var
              # Prints 1: makes sense, no word splitting here
              
              var=(array 'of strings')
              argn $var
              # Prints 2: makes sense, I'm using a 2-wide array where I would
              #           want 2 arguments (the second one happens to have
              #           a whitespace in it)
              
              # Bash
              function argn { echo $#; }
              
              var='spaced string'
              argn $var
              # Prints 2: non-array variable gets split in 2 with this simple reference;
              #           I hate it, but hey, it is what it is
              
              argn ${var}
              # Prints 2: no, braces do not prevent word splitting as I think you suggested
              
              var=(array 'of strings')
              argn $var
              # Prints 1: ... what?
              
              echo $var
              # Prints array: ... what?!?
              #               It implicitly takes the first element?
              #               At least it doesn't word-split said first element, right?
              
              var=('array of' strings)
              argn $var
              # Prints 2:
              


              Upon further investigation:

              # Bash
              mkdir /tmp/bashtest ; cd /tmp/bashtest
              touch 'file 1'
              touch 'file 2'
              
              stat file*
              # Prints the expected output of 'stat' called on both files;
              # no quotes or anything, globbing just expands into
              # 2 arguments without *word* splitting
              
              files=('file 1' 'file 2')
              stat $files
              # stat: cannot statx 'file'
              # stat: cannot statx '1'
              # WHY? WHY DOES GLOBBING ACT SENSIBLY WHEN ARRAYS DO NOT?
              

              I get that the Bash equivalent to Zsh’s $array is ${array[@]}, but making $array behave like it does in Bash has no advantage whatsoever.
              … IS WHAT I WOULD SAY IF THAT WERE TRUE! YOU ALSO HAVE TO QUOTE "${array[@]}" BECAUSE WE LOVE QUOTES HERE AT BASH HQ!

              # ... continued from before
              stat "prefix ${files[@]}"
              # stat: cannot statx 'prefix file 1'
              # (regular 'stat' output for 'file 2')
              

              While this behavior doesn’t make much sense to me, it also doesn’t make sense for me to write that “prefix” within the quotes in the first place, right?
              YES. BECAUSE SPLITTING IS NOT WHAT YOU EXPECT WHEN YOU PUT STUFF IN QUOTES.

              Sorry, I’ll stop.

              • ronigami@lemmy.world
                link
                fedilink
                arrow-up
                3
                ·
                1 month ago

                My bad, I was thinking of zsh. And I think it’s configurable there too so may not behave that way according to your settings. But it is at least the default on Mac.

                • Sonotsugipaa@lemmy.dbzer0.com
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  edit-2
                  1 month ago

                  I use Zsh too, though at this point is becoming detrimental to my (already limited) Bash skills because of features like the ${^array}{1,2,3} syntax which I use in some scripts of mine, which in turn I wouldn’t dare try to translate to Bash.

  • bob_lemon@feddit.org
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    1 month ago

    My work has me working with Matlab Simulink paths, which may (and sometimes actually do) contain newlines.

  • Lyra_Lycan@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    1 month ago

    Windows is stupid as shit, trying to shift+right click > open Powershell in a path containing a space results in it throwing an error, and you have to paste the path in yourself anyway

  • Luc@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    1 month ago

    Now I’m imagining a shell that looks iteratively through arguments to find where quotes would make total sense

    $ ls
    my victims.ods
    $ wipe -f my victims.ods --thorough
    

    So the shell would go like

    1. wipe → command name found, ok
    2. -f → no file in the current directory starts with that, skip
    3. my → matches a file, keep in memory…
    4. my victims.ods → full match, but missing quotes!
    5. Prompt user:
    Filename "my victims.ods" found without quotes. Choose:
    [a]dd quotes this time
    [A]lways add quotes (dangerous)
    [n]o quotes today please
    [N]ever offer adding quotes again
    [t]ell me what could possibly go wrong when I choose to always add quotes
    [P]unch the person who proposed this feature
    
    • BatmanAoD@programming.dev
      link
      fedilink
      arrow-up
      4
      ·
      1 month ago

      For interactive use, tab-completion essentially makes this a non-issue, because shells add escaping in the appropriate places.

      For scripting, where spaces are harder to deal with, unfortunately there’s just not much you can do; your two options are basically to learn all of your particular shell’s patterns for dealing with whitespace in filenames, or only write scripts in something other than a POSIX shell.

      • Luc@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 month ago

        Scripting isn’t the issue, but for tab completion: the boundary is often at a space or parenthesis so that you need to type the backslash + char to continue tabbing to completion

        • BatmanAoD@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 month ago

          Believe me, whitespace-correct scripting is absolutely an issue.

          You’re right that it’s annoying when filenames diverge right at a character that must be escaped.

  • MehBlah@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 month ago

    End each word with a . Pretty simple. I just realized lemmy wont show a forward slash.