6 ms·

Can you use spaces in filenames with GNU make yet? Seems like a 47yo vestige when spaces in filenames weren’t really a thing…

colonwqbang 3y ago
Do we know that taskfile does any better than make on this front? It isn't mentioned in the article. Sounds like taskfile is runs on raw "command line string interpolation" just like good old make.
rwmj 3y ago
Does this suffer from all the common problems with yaml (like the "Norway problem", but many others)?
- R0flcopt3r 3y ago
  What is the "Norway problem"?
  - signa11 3y ago
    “The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing list of countries f.e ‘[GB, IN, NO,…]’
    - throwaway83i3r 3y ago
      It's a good example of how you can overengineer a relatively simple format. The reason is that they specify a boolean value as either "true/false" or "yes/no". The last alternative causes problems not only for the Norwegian country code (no), but also in cases where you need to specify the actual word "yes" You could of course end up with the same problem if you need to specify the literal "true" and "false", but by overengineering the acceptable boolean values, they increase the potential problem areas.
      - Brian_K_White 3y ago
        Claiming more common words as keywords basically. It's just not well considered. true and false are ordinary words, and it would probably be better if sometime way back someone had come up with special keywords that didn't conflict with ordinary words, but for good or bad, at least by now it's practically universal in most languages that true & false are keywords and everyone knows it. Claiming yes and no as keywords also was just thoughtless and inconsiderate (ok that was redundant), doubly so when they don't even do a new job but simply double the consumed namespace to do the same job that was already done by true & false.
        SAI_Peregrinus 3y ago
        Eh, it's fine if they're keywords as long as not everything is a string. If `"NO"` and `NO` are distinct types, then they're not equal and there's no Norway problem. YAML treats strings, numbers, null, and booleans as all the same type (scalars). The problem isn't keywords clashing with common words, it's not having distinct types!
      - izoow 3y ago
        There's even more options apparently :) A Boolean represents a true/false value. Booleans are formatted as English words (“true”/“false”, “yes”/“no” or “on”/“off”) for readability and may be abbreviated as a single character “y”/“n” or “Y”/“N”. Regexp: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF (https://yaml.org/type/bool.html https://yaml.org/type/bool.html)
      - Fire-Dragon-DoL 3y ago
        To be fair, yaml has a form of inheritance, I wouldn't define it a relatively simple format
    - unscaled 3y ago
      To be fair, YAML 1.2 does not suffer from the "Norway Problem", but YAML is still a rather complex format. I feel like the Makefile syntax has some pesky warts, like not breaking when there are spaces in filenames, requiring tabs[1], the ceremony around PHONY targets... If you take the legacy stuff out of make, [1] Apparently it can be fixed with a complex .RECIPEPREFIX incantation which behaves differently in different versions of GNU make, and was conveniently added just one minor version after Apple has graciously decided to stop updating all their GNU software versions. Redo, ninja and tup seems like trying to do that, with their own twists, but none of them really managed to nudge make out;
      - gjvc 3y ago
        I use make for (among other things) transforming files; batch compression being the simplest example, so all one requires is a rule saying %.log.xz : %.log and all is well. But if people have colons in filenames, for example for timestamps, all bets are off, and make chokes spectacularly.
        lolcatnip 3y ago
        And that really sucks in Windows because every absolute path contains a colon. Not that absolute paths are common in makefiles, but it's not something that should break on a major platform.
cjfd 3y ago
Or just don't use spaces in filenames. It just causes trouble for no benefit.
- meling 3y ago
  Oh yeah, tell that to Dropbox.
  - rakoo 3y ago
    Don't use dropbox. That's not even just a thing to say, reclaim your autonomy and stop using a proprietary tool.
    - Novosell 3y ago
      No doubt sent from a device with fully open-source hardware stack, right?
      - rakoo 3y ago
        Is it conceivable to you that steps are possible, and getting rid of dropbox is a step in a direction ? That perfect is the enemy of good ? That you can't wait to find a perfectly pure plan before starting moving ?
- deleted 3y ago
  [deleted]
- inopinatus 3y ago
  rather fond of leading hyphens and nonprint ascii myself
- jen20 3y ago
  Ah yes - the user should serve the computer, not vice versa, clearly. /s, in case it's necessary.
  - Kamq 3y ago
EuAndreh 3y ago
In GNU make? Actually, yes: $ cat Makefile a\ file: ; echo 123 > '$@' $ make echo 123 > 'a file' $ cat a\ file 123
- booi 3y ago
  AFAIK this does work but it’s a limited workaround. Make in general just does not support file names with spaces well. http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712 That being said… In projects I just avoid filenames with spaces in general

colonwqbang 3y ago

Do we know that taskfile does any better than make on this front? It isn't mentioned in the article. Sounds like taskfile is runs on raw "command line string interpolation" just like good old make.

rwmj 3y ago

Does this suffer from all the common problems with yaml (like the "Norway problem", but many others)?

R0flcopt3r 3y ago
What is the "Norway problem"?
- signa11 3y ago
  “The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing list of countries f.e ‘[GB, IN, NO,…]’
  - throwaway83i3r 3y ago
    It's a good example of how you can overengineer a relatively simple format. The reason is that they specify a boolean value as either "true/false" or "yes/no". The last alternative causes problems not only for the Norwegian country code (no), but also in cases where you need to specify the actual word "yes" You could of course end up with the same problem if you need to specify the literal "true" and "false", but by overengineering the acceptable boolean values, they increase the potential problem areas.
    - Brian_K_White 3y ago
      Claiming more common words as keywords basically. It's just not well considered. true and false are ordinary words, and it would probably be better if sometime way back someone had come up with special keywords that didn't conflict with ordinary words, but for good or bad, at least by now it's practically universal in most languages that true & false are keywords and everyone knows it. Claiming yes and no as keywords also was just thoughtless and inconsiderate (ok that was redundant), doubly so when they don't even do a new job but simply double the consumed namespace to do the same job that was already done by true & false.
      - SAI_Peregrinus 3y ago
        Eh, it's fine if they're keywords as long as not everything is a string. If `"NO"` and `NO` are distinct types, then they're not equal and there's no Norway problem. YAML treats strings, numbers, null, and booleans as all the same type (scalars). The problem isn't keywords clashing with common words, it's not having distinct types!
    - izoow 3y ago
      There's even more options apparently :) A Boolean represents a true/false value. Booleans are formatted as English words (“true”/“false”, “yes”/“no” or “on”/“off”) for readability and may be abbreviated as a single character “y”/“n” or “Y”/“N”. Regexp: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF (https://yaml.org/type/bool.html https://yaml.org/type/bool.html)
    - Fire-Dragon-DoL 3y ago
      To be fair, yaml has a form of inheritance, I wouldn't define it a relatively simple format
  - unscaled 3y ago
    To be fair, YAML 1.2 does not suffer from the "Norway Problem", but YAML is still a rather complex format. I feel like the Makefile syntax has some pesky warts, like not breaking when there are spaces in filenames, requiring tabs[1], the ceremony around PHONY targets... If you take the legacy stuff out of make, [1] Apparently it can be fixed with a complex .RECIPEPREFIX incantation which behaves differently in different versions of GNU make, and was conveniently added just one minor version after Apple has graciously decided to stop updating all their GNU software versions. Redo, ninja and tup seems like trying to do that, with their own twists, but none of them really managed to nudge make out;
    - gjvc 3y ago
      I use make for (among other things) transforming files; batch compression being the simplest example, so all one requires is a rule saying %.log.xz : %.log and all is well. But if people have colons in filenames, for example for timestamps, all bets are off, and make chokes spectacularly.
      - lolcatnip 3y ago
        And that really sucks in Windows because every absolute path contains a colon. Not that absolute paths are common in makefiles, but it's not something that should break on a major platform.

cjfd 3y ago

Or just don't use spaces in filenames. It just causes trouble for no benefit.

meling 3y ago
Oh yeah, tell that to Dropbox.
- rakoo 3y ago
  Don't use dropbox. That's not even just a thing to say, reclaim your autonomy and stop using a proprietary tool.
  - Novosell 3y ago
    No doubt sent from a device with fully open-source hardware stack, right?
    - rakoo 3y ago
      Is it conceivable to you that steps are possible, and getting rid of dropbox is a step in a direction ? That perfect is the enemy of good ? That you can't wait to find a perfectly pure plan before starting moving ?
deleted 3y ago
[deleted]
inopinatus 3y ago
rather fond of leading hyphens and nonprint ascii myself
jen20 3y ago
Ah yes - the user should serve the computer, not vice versa, clearly. /s, in case it's necessary.
- Kamq 3y ago

EuAndreh 3y ago

In GNU make? Actually, yes: $ cat Makefile a\ file: ; echo 123 > '$@' $ make echo 123 > 'a file' $ cat a\ file 123

booi 3y ago
AFAIK this does work but it’s a limited workaround. Make in general just does not support file names with spaces well. http://savannah.gnu.org/bugs/?712 http://savannah.gnu.org/bugs/?712 That being said… In projects I just avoid filenames with spaces in general