Hacker News Reader

Comment by neonscribe | Hacker News Reader

I used make heavily in the 80s and 90s, but haven't much since then. Recently I started a project that had source files getting processed into PDF files, for use by humans. Since this is the 21st century, those files have spaces in their names. At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile. A little searching reveals that the consensus on using make with files with spaces in their names is simply "don't even try." In the 21st century, this is not an acceptable answer.

View on HN

Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one? While you are allowing spaces, you probabaly are allowing all possible code points or maybe even a null byte? Thinking about it gives me headaches.

I hate hearing people using 21st century or modern as reasons for inflating complexities. Without rein on complexity (whether it is hidden or not), the future is doomed, whatever you are building. While I am not saying we should avoid complexity at all cost, I am insisting that all complexity should be balanced with merits.

The merits of filenames with spaces is they read better in a GUI explorer. Whether that merit balances out all the complexity it brings is individual dependent. For me, that merit ranks very low and I avoid spaces in my filenames at all opportunities. For some, they need those filenames to be readable. And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Another solution would be to add an additional pre-step of copying/renaming/linking/aliasing. With the latter solution, the complexity is confined.

I guess for some, it only matters with "I do work" or "they do work" rather than the big picture. That is fine. However given the context of you are working with Makefiles, then you are a developer at some level, you are supposed to do some work.

get out of here spaces.

What does the merit of spaces in file names matter? You still will need to deal with files with spaces in the real world. If your tooling doesn't support it, it's a non-starter for many.

What about real world is that in real world, it is not context-free. There are real world situations -- such as selling a word processor to general public (especially) including clueless -- you need to deal with files with spaces, period. But there are real world situations -- such as Makefiles -- requires users to learn the tool, to be able to handle certain tricky situations themselves and excludes incompetents. And then there are real world situations that the application only concerns within a company, or within an office, or within one-self.

What about real world is, it is complicated.

I'm bemused by this repeated insistence that supporting spaces in file names is somehow difficult.

The word was complicated, not difficult. It is not difficult to handle spaces, it is more complicated.

That's a worthwhile clarification - thank you. While that's certainly true in the strict sense, I remain bemused.

I'm bemused by this repeated insistence that supporting colon in file names is somehow difficult.

Who on earth insists that? Only Windows programmers, I expect! But it's easy: make sure they're expressible in your syntax, then pass them through as part of the file name. Just like spaces. If there's a problem, you'll get an error back from the OS.

Yes, of course you're right. My apologies, it was a stupid comparison.

Though I still feel it's a bit of "choose your poison". In any language, certain symbols will have special meaning. You pretty much have to pick which ones, and come up with rules about how to let their natural meaning bleed through. With unix shells, one such character is the space, and there's a number of rules about how to let their natural meaning bleed through - but they're all somewhat awkward, and they all need special care.

And nulls? And quotes? And dollars? And any unicode char?

I expect you mean NUL (ASCII 0) - but that's typically not a good choice, because POSIX decrees it invalid, along with '/'. But anything else is fair game, sure. Handling every Unicode char might be a pain, but that's the filing system's job, not yours!

Most programming languages manage to get this right. You have a quoting syntax with an escape character that lets you express the quotes, the escape character, and any arbitrary character (as a byte sequence, as a Unicode codepoint in some encoding, etc.) as well. Now you can do everything. Why not do this?

I'm not going to say this won't be a pain if you decide to write out every file name possible, because it will be, inevitably. But you can supply alternative syntaxes by way of more convenient (if limiting) shorthand - Python has its r"""...""" notation, for example, allowing you to express the majority of interesting strings without needing to escape anything.

You might argue that I've just punted the problem on to the text editor and the filing system. You'd be quite right.

Depends very much on your programming environment: on Python I don"t care, but when doing bash scripting or makefiles (very often) I very much care.

I have recently decided to stop using $ in passwords (defined by me) for that same reason: of course they are valid char, but they are such a big pain to support in usual contexts that it is simply not worth it.

And regarding slashes: are you bemused that unix does not support them in filenames?

(Thanks for correcting the nul reference)

No, not really - I have no particular opinion about what POSIX chooses to support or not.

But I'm going to go back to my original point. What I do have an opinion about is how reasonable it is for tools not to support a character that is valid in file names, when that character is straightforward to support with everyday, well known syntax.

And when that character is ' ', the standard English word separator, as straightforwardly supported by approximately ever kind of quoting or escaping syntax ever, my opinion about a lack of support is: it's crap.

Please write a makefile that uses an environment variable as a mysql password to connect to a mysql server and perform an arbitrary administrative task.

Now do the same, assuming that the password can have a dollar in it.

You can do it. It is not as easy, readable or maintanable. Avoid it if you can.

Not a problem if you use a my.cnf file...

And I need that because of ... a dollar!

Extra complication to avoid if possible.

Why do it from a makefile instead of a script called by the makefile? This plays well to the strengths of both.

Just because of the dollar? Exactly my point.

No, not just because of the dollar. Because it's easier to test in isolation and allows you to use things like here docs which are useful for dealing with sql.

Somehow we started with a single dollar in a string, and now I am dealing with sql, here docs, and TDD?

There is a place for everything in life: for small helper makefiles, which I write simply to support me in my workflow and even to remember some interesting commands that I need to run for a certain project, I can assure you that making some simple assumptions helps me staying halfway sane.

This represents a problem with make, not any other part of the system.

You’re trying to “sell” make. It is lacking a feature many of its competitors have. That’s a tough sell :)

Your tools support filenames with tabs? With any unicode char?

A real world possibility.

works in bash:

> touch "with<Ctrl+v><Tab>tab"

Exactly as easy as without tabs. Now do that the whole day, sometimes with tabs, sometimes without.

Every project I develop is unit tested with strings containing invalid unicode text, containing null bytes, and other random stuff.

If a user can’t paste any byte sequence, and expect it to work, then the tool is broken. I handle these cases.

You can do it. The question is whether you should if you can avoid it.

When writing a shell script or makefile to deal with repetitive tasks if is easier to assume some things.

I'd prefer it if the writer of the shell or make didn't make too many assumptions about my assumptions.

Even bash lets you escape unusual filenames for when you need them. Make will always explode your strings, and doesn't even attempt to let you escape them. I don't think it's unreasonable to expect a time-tested Unix tool dealing with files to actually handle all possible files.

So in order to deal with the real world possibility of spaces in filenames you choose to ditch a real world, useful tool?

Perfectly reasonable if spaces in filenames are a hard req.

In lots of scenarios they are not, and I prefer to assume that filenames have no spaces, and stick to make.

> At a certain point, I realized that I should be managing this processing somehow, so I thought of using a simple Makefile.

I don't understand why one would think that make would be a good tool for this...

> Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works and other delimination schemes are much more error prone -- forgetting balancing quotes, any one?

Yes this is a limitation of make, but not a million other tools out there.

Make is not a panacea, no tool is - pressing a tool into a job it is un-suited for because you understand it is "Not good" (trade mark and copy right pending).

This is the classic case of having a hammer and a screw -

> I don't understand why one would think that make would be a good tool for this...

Why not? To me, it sounds like a perfect use of Make. You have a number of files that should be processed somehow (presumably by invoking a certain tool for each and every file) and produce another set of files.

Whether it's C-files to compiled binaries, or some source files to PDF:s, make seems very well suited for the job. Except yeah, perhaps, spaces.

Yeah make seems like a great first tool to grab in this case. But apparently some of the requirements of this current usecase don't play well with make. Too bad, but it doesn't mean make is somehow a bad tool...it just doesn't fit all problems.

Given that make isn't working well in this case due to spaces, I would personally probably use something like find and sed in a bash script to just get all the files and convert them to pdf. (Obviously this won't work if your system doesn't have these tools though...)

I hate hearing people using 21st century or modern as reasons for inflating complexities.

No. He's right, you're wrong, hzhou321. We want spaces in filenames. We even want UTF-8 if possible. We don't want crude tools that cannot handle the most basic names. You can argue all you want, this is a very very basic demand that could be met with very very basic tools but make is just too crude.

People like you are exactly the cancer in the developer community that argues away reasonable demands like spaces in filenames and perpetuates the garbage legacy tools we have.

> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think.

Users expect computers to work in a non-surprising ways.

It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one more way that computers are scary and unpredictable.

Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.

> Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.

That is an excellent example that deserves a second look from a different aspect.

... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.

Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs).

And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.

Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.

> Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly ...

Just to clarify on what we think as problem could differ:

    C:\Users\hzhou>ls *.txt
    new  2.txt

    C:\Users\hzhou>ls new  2.txt
    ls: new: No such file or directory
    ls: 2.txt: No such file or directory

dir works fine for that.

I actually didn't know that dir supported multiple globs for filenames! I've never had a need for that.

Super cool.

Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting.

Directory of C:\Users\fred

12/14/2017 04:44 PM 1,556 new 2.txt 1 File(s) 1,556 bytes 0 Dir(s) 75,989,876,736 bytes free

C:\Users\fred>dir new 2.txt Volume in drive C has no label. Volume Serial Number is BA05-C445

Directory of C:\Users\fred

File Not Found

C:\Users\fred>

> Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting.

Ah I see, you have a file "new 2.txt", I was a bit confused.

Not sure what you mean by only 1 level of quoting being a problem, sorry.

> Ah I see, you have a file "new 2.txt", I was a bit confused.

This is highly ironical, given this thread.

Some people seems to advocate for programs to be better than humans at globbing filenames.

That's a great point. Computers sure have the potential to deal with spaces just fine. But if textual interaction is a requirement, we can only have one of arbitrary filenames and clutter-free syntax.

Window and Linux shells have the same ideas about spaces in file names, which is that if they appear they need to be quoted or the space character needs to be escaped.

Outside of Make which has long and boring historical reasons for not supporting spaces well, just about every program is fine with spaces.

In UNIX shell, IFS variable can be set to an other characters, e.g. newline and tab, or to empty string.

> Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs,

A similar trend is happening in electronic communication: from letter to email, to text, to emoji's. The text is just one historical communication way and there's no reason it should be of any real interest to modern communicator as long as we have emojis ... wait, we've been there before.

Only the text can express things that emojis cannot. This is not true to GUI vs command line.

The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.

This kind of interface is horrific for the use-case:

https://www.powergrep.com/screens/replace.png

There is such a thing as a cluttered graphical interface, and some complexity cannot just be abstracted away.

> The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.

That would be like saying that because I am able to write "First open this app by clicking on the upper-left icon, then click File, new File", would mean that text is a superset of the GUI because it can describe visual cues. An abstraction can always replace another, it does not mean it is a superset of it.

Take the source code for your GUI application, this is pure text. In the early days, there was shell code that would describe terminal GUI of sort to configure the linux kernel. This shell code is still commands read token per token with matching behavior. Because an abstraction can be traded for another (which could be argued to be a founding principle of computer science), does not mean that one is a superset of the other.

To be fair to modern desktop users, a command line that doesn't redefine the word "command" to fit the constraints of the system would look something like this:

$ take this list of transactions and for each group of duplicate names show me the name and total dollar amount spent, sorted from highest to lowest

$ I think I have a SQL command for that. Are you feeling lucky? [y/n] y

Foo $25 Bar $20 Blah $15

$ Was this what you were looking for? [y/n]

> it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem.

There is nothing beneath the Windows UI interface. The GUI is the primary subsystem of Windows, the command line is a separate subsystem. Windows has traditionally been built up around the Win32 API, which is GUI first.

It is of course possible to do things from the command line, and some advanced stuff may need the command line, but users should never need to drop out of the UI unless something has gone horribly wrong.

The Windows UI is incredibly powerful, with advanced diagnostic and logging capabilities, incredible performance monitoring tools, and system hooks everywhere that allow the entire UI to be modified and changed in almost any way imaginable.

The way Services work on Windows is not some (hotly debated) config files. It is through a UI. Management of hardware takes place through a UI. Pretty much everything short of running Ping has a UI around it.

I love the command line, if I am developing it is how I primarily work. And while doing so, younger devs look at me like I am crazy because they have customized the living daylights out of their UI tools (VS Code, Atom), to do amazing things that exceed what a command line can do, and of course those editors have a command line built in for when that is the best paradigm!

> and having it heavily disguised as an appliance is mandatory.

Something working so well that it becomes an appliance isn't a bad thing. It means the engineers who made it have put in so many fail safes and worked to make the code of high enough quality that it doesn't fall apart around itself all the time.

Heaven forbid I can upgrade my installed software and not have some random package break my entire system.

> There is nothing beneath the Windows UI interface.

To clarify, beneath the GUI interface is the actual code that implements that interface.

> Something working so well that it becomes an appliance isn't a bad thing.

Not at all. I don't attempt to call or think my phone as an computer. Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances. It is just that there are still a big camp of people who use a computer as computer. That causes some confusions in the communication between.

> Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances.

It seems that 90% of computer use has moved into the web browser. Heck outside of writing code, almost everything I do is in a browser, and my code editor of choice happens to be built as fancy skinned web browser...

> To clarify, beneath the GUI interface is the actual code that implements that interface.

I'd say that everything moving onto the web has once again made the code underneath it all accessible to the end user, if they so choose.

(Ignoring server side)

> It seems that 90% of computer use has moved into the web browser.

This is an extremely (web) developer-centric viewpoint IMHO.

Try telling 3D modellers/sculptors, games programmers, audio engineers that 90% of their computer use has moved into a browser. They will look at you with a blank face since they all require traditional "fat" desktop apps to get their work done at professional level.

And those are just the examples I can find off the top of my head, I'm sure I could think of more.

Do all of those computer users constitute more than 10% of computer users? I don't think there's even 5% of computer users there.

Talking about 3D modelling, game programming and producers like they're the majority is a technologist-centric view.

Most computer use is by people who think the web is the internet and use 'inbox' as a verb.

> Do all of those computer users constitute more than 10% of computer users? I don't think there's even 5% of computer users there.

So as stated that was the list of the top of my head. I just pulled from my personal list of hobbies, things that I use a computer for other than programming or automation.

Within 50 feet of me at work there are a whole bunch of electrical engineers who spend 90% of their time in some fat app for designing, I dunno, telco electrical stuff.

In the fishbowl next to that, are 50 network operations staff who spend 90% of their day in "fat" network monitoring applications.

I'm just pointing out if you look far enough there are plenty of people using apps outside a web browser for their daily work and hobbies.

In my nearly 25 career in IT I have never heard people use 'inbox' as a verb (as in 'inbox me?'). Sure some people must say it sometimes, but I think this is overstated and another example of programmer cliche or hyperbole.

Most computer use is by people who think the web is the internet and use 'inbox' as a verb.

I think most of those people dont use general purpose computers anymore

> Try telling 3D modellers/sculptors, games programmers, audio engineers that 90% of their computer use has moved into a browser. They will look at you with a blank face since they all require traditional "fat" desktop apps to get their work done at professional level.

I'm talking about overall computer use. For certain professional fields, yes, apps still matter. But I'd take a guess that the majority of screen time with computers now days involves a web browser.

Heck as a programmer (not web), I am probably 50% in browser looking things up.

At most offices, computers are used for web browsing, and Microsoft Office.

> Heck as a programmer (not web), I am probably 50% in browser looking things up.

I should have put web in square brackets eg. [web] to indicate "optional". You seem to fall into the category I was describing.

Use an IDE (other than Atom), eg. Visual Studio, Eclipse, IntelliJ? All fat apps.

Use VMware workstation or Virtualbox? Fat apps.

> At most offices, computers are used for web browsing, and Microsoft Office.

So is that 90% web browsing and 10% MS Office? BTW, Office365 is still fat application (or suite of them) last time I looked.

Those PC-as-appliance people are better served in the mobile space and it would be best if they left us and our computers alone

> There is nothing beneath the Windows UI interface.

> Windows has traditionally been built up around the Win32 API, which is GUI first.

What did I just read?

>There is nothing beneath the Windows UI interface.

Yes there is .. Microsoft! For instance if you have a dir named "user" it will show up in your GUI as "User". In fact User, USER, user are all the same for you because MS transliterate on the fly. Did you know that you cannot access some directory because MS prevent it .. event with the 'dir' command from the DOS prompt .. only an 'ls' non-MS command can do that.

> Users expect computers to work in a non-surprising ways.

"Users" is a very broad category with a bunch of partitioning.

The particular subgroup in question are authors of build automation systems for medium to large scale software projects. They (we) have a rather different perspective on "surprising".

> authors of build automation systems for medium to large scale software projects

For desktop software, a build automation system needs to handle files that are included in the installer, installed on user’s machines, and in some cases be discoverable by end users of the software.

I would be very surprised if my build system wouldn’t support spaces in file names.

Windows land also had https://en.m.wikipedia.org/wiki/8.3_filename which was never confusing.

Users aren't programmers and programmers write things no user should ever see. Only the machines do.

"users" of Makefiles are actually developers, not secretaries, pensioners or architects. They should at least understand tradeoffs and choose accordingly.

Developers are used to not using spaces: oneStupidClass or AnotherStillStupidClass or others_do_it_like_this or bIhatehungariannotation or daxpy .

As you can see it is not that bad and it has been a widely used practice for decades.

Since you are comparing specifically to windows land, perhaps it is their focus on using spaces in file names that made them always be worst than unix like systems in terms of stability, sequrity or performance.

Human beings who name things are going to use spaces. That spaces were used as delimiters for computers is somewhere between unfortunate and a colossal mistake.

But to use that as evidence of why spaces should not be supported in filenames is putting the cart before the horse. The goal of software is not to perpetuate whatever mistakes have been made in the past. It's to solve problems for human beings.

And human beings have been using spaces to delimit words since long before computers existed.

On the command line, using spaces to delimit words is also quite natural; that's why they get used as a delimiter:

    mv old-file new-file

Spaces separate the verb, the direct object, and the indirect object. Using commas or colons instead would painfully artificial.

So the question is whether you will favor naturalness on the command line or in the GUI. It's no surprise that a Unix build tool favors the command line.

True, but on the command line I don't have to worry about the spaces. I'm just going to tab-complete to simultaneously ensure I'm in the context I expect to be in, ensure I'm not making any typos, and save some time to boot.

What if your file system didn't distinguish between underscores and spaces, your GUI displayed them as spaces, and your command line displayed underscores?

Then this problem goes away entirely and you instead have the problem of not being allowed to have "this_file" and "this file" in the same directory. A problem which probably doesn't matter.

That hides the problem from the user, and will consequently lead to command line users typing spaces where they should be typing underscores.

To clarify our views:

The words and sentences are inside the file. The filenames are identifiers to the files. Identifiers' purpose is mainly to identify, rather than to communicate.

On the other hand, we could imagine a user interface that users don't see (actual) filenames at all.

Identification is a form of communication.

The identifier assigned to me at birth contains two spaces. Most people use one of the shorthand forms, but still.

I'm intrigued. Your first name has two spaces in it?

That is, I think it is safe to say that we expect we can include spaces in the names of things. The movie is named "Star Wars", after all. That seems natural.

For people, though, we have grown used to someone having multiple parts of their name separated by a space. If given out of order, a comma.

Even in the "naming things" category. We are used to having to put quotes around names that have spaces. Or otherwise using a convention like Capitalized Identifiers to show something goes together. Probably isn't a clearcut rule.

> I'm intrigued. Your first name has two spaces in it?

No. But my name does.

> For people, though, we have grown used to someone having multiple parts of their name separated by a space. If given out of order, a comma.

https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

Ok. Something about the way I read the first post, I thought you meant your simple name. No reason it couldn't have spaces. My wife knew of someone named 1/2. Insisted it be a single character, too. Was amusing how hard that was for most payroll systems.

And I wasn't saying this isn't allowed. What we are used to is not the total of what is allowed. The fringes are full of mistakes, though. At some point, you make a statistical choice.

Not all languages have (or had) spaces.

I apologize if I implied that they did, because that has nothing to do with my intended message.

You solution is a “boil the oceans” one typically proposed by engineers. You can re-program computers. You can’t re-program millions of people. Every natural language uses spaces to separate things.

You can accept that or you can keep tilting at windmills.

In every branch of science, reality wins. If your model can’t accomodate reality it’s either completely wrong or it needs adjustments, at least.

> Every natural language uses spaces to separate things.

Exactly. To separate things. Which, incidentally, happens to also be precisely what make, and the traditional UNIX shells do :-)

The problem isn't that space in itself is a particularly difficult character. The problem is that its meaning is overloaded and ambiguous. No matter what you do, computers will have difficulty with ambiguity. You'll always have the problem that the separator is special, but hey, I'd be all for using 0x1C instead ;)

How exactly is this different to, say, maths, where there is an assumed precedence and when you need to either make that clear or change the order you use parentheses to encapsulate the inner calculation?

What it sounds like is that the Unix shell syntax was established how it was, everyone built on it with all of its syntactical conveniences, and suddenly there's 100% buy-in to the idea that a computer just can't handle a filename with spaces in a shell.

    ./cmd do-something-with --force file with spaces


    ./cmd do-something-with --force 'file with spaces'

That's one of the main problems solved. If you're expecting to run an executable with spaces in it, like this:

    ./do something with cmd --force 'file with spaces'

Then it's another problem but one that can be solved by convention. A GUI can happily execute `./do\ something\ else` but if you're in the shell you've got completions, aliases, functions, symbolic links...

And if that's not ideal, then `./'do something with' cmd …` should be good enough right?

You can prevent your tools from having to deal with the fact, by preprocessing.

> Every natural language uses spaces to separate things.

Nope. You don't space out each word when speaking. If you were speaking about writing systems, not all writing systems use spaces as word delimiters. See: https://en.wikipedia.org/wiki/Space_(punctuation)

>Demanding the support of spaces in filenames significantly complicates code as simple space delimination no longer works

Wow.

So human beings should stop using allowed file names because it's too hard for you?

The fact that Unix tools have trouble with spaces in filenames is absolutely a problem with Unix. If the Unix ecosystem had better support for this, then it wouldn't be a problem.

Unix tools have no trouble with space in file names. "-", "\0", "\n" and bad Unicode are troublesome. Lazy programmers can forget to put quotes around variables in shell scripts, but it's not a problem of the tool.

Additionally, not every shell expands variables the way Bourne-based shells do.

I don’t quite see how Unix tools have trouble with spaces in filenames. Could you detail some cases where the space handling is not due to the shell, as opposed to the program being invoked?

There's this program called make...

My question was aimed at ops generic statement. As for Make, it originally wasn’t clear to me where the issue was supposed to lie. Lines in rule bodies are handed off to the shell, and that whitespace in rule dependencies need escaping didn’t seem surprising since it’s a list (though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon). But I see now that the expansion of list-valued automatic variables is probably a real Make-endemic issue.

> though it’s probably a bug that whitespace in target names must be escaped, since it’s just one token that ends in a colon

It's perfectly fine for a rule to have multiple targets, e.g.

  output.txt error.txt: source
    build source > output.txt 2> error.txt

Interesting! So in that case one could defend the need for escaped whitespace. Still leaves automatic variables, I guess.

Well it could be rewritten to use 0x1f (i.e. unit separator) to separate items. I mean it already has significant tabs. Though invariably people would be like "How is it acceptable for make to not support filenames which contain unit separators? It's 2020 guys, get with the program!"

Nothing an intake script and a little gsub() can't handle

I am old-school and hate spaces. They do occasionally show up on my computer. But never in anything I'd be touching with a Makefile.

You're talking about implementation complexity. The only argument you can throw at the user is feature complexity. Handling spaces in filename isn't a complex feature at all, and users don't care that the simplistic implementation you're using makes it a problem.

Not handling spaces is a symptom of a much deeper problem in common with a lot of 'unix' utilities: not actually structuring data apart from in ad-hoc string encodings. The fact that data can be so easy conflated with program structure is the cause of so many obscure bugs and overhead in using utilities that suffer from it it's a wonder anyone is defending this approach going forward.

> The merits of filenames with spaces is they read better in a GUI explorer.

Even this merit is debatable. Is foo bar two things or one? I know foo-bar is one.

yeah and then is 田中 one or two things? It all depend on the domain. To me 'é' and 'ê' mean different thing that are both outside the make domain. In French you also have half white space (diacritic that latex can handle) for terminal '?!..' Those are simply outside make domain .. so bothering about space encoding as: ' ', '+', "%20" or '_' seem futile.

It all depend of domain convention. Make align on variable naming convention .. that is all

I've been working with strings with spaced since before the 21st century. I've also worked with strings with special characters.

I've even worked with variables with spaces and special characters.

I don't see why filenames are so much more special, except a lot of old tools never got updated to world beyond ASCII

I was able to to it. Here's the source code "hello world.c":

    #include <stdio.h>
    
    int main(void)
    {
      puts("Hello, world!");
      return 0;
    }

And here's the minimal Makefile to generate the output:

    hello world:

Of course, I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160) to get this to work, but hey, spaces!

>I did have to swap out the ASCII SP (character 32) for the Unicode non-blank space (code 160)

How?

EDIT: Ok, now I got it. Boy that was a wild ride.

Could you explain how you did it?

Replacing breaking space with non-breaking space :

1. Set up your compose key on linux(Top right corner settings->system settings->keyboards->shortcut->typing->Compose key(choose an appropriate one)).

2. Whenever you need to type breaking space instead type (compose key + spacebar + spacebar). This puts a non-breaking space there instead. That's it.

3. Create file -> sudo nano hello(compose key + spacebar + spacebar)world.c

4. Paste the code to execute.

5. Makefile-> hello(compose key + space + space)world:

6. make

7. ./hello world (pressing tab will recognise the executable automatically).

NOTE: Don't do this ever in any production code or just ever. This hack can take up hours to resolve and a lot of frustration which could have better been spent on fixing something meaningful. This is a frowned upon practice. The only cool part is that your directory can have two files with whose name look exactly the same.

I did not do the method below. Instead, I wrote a script to generate the filename with the non-breaking space where I needed it.

Edit: rewording and typos.

Any way I can see the script? Looks like I am still learning and ended up taking a longer route.

It's Lua 5.3:

    h = "hello" .. utf8.char(160) .. "world"
    
    f = io.open("Makefile","w")
    f:write(h,":\n")
    f:close()
    
    f = io.open(h .. ".c","w")
    f:write([[
    #include <stdio.h>
    
    int main(void)
    {
      puts("Hello, world!");
      return 0;
    }
    ]])
    f:close()

Pretty straightforward.

Solution: create the pdfs with spaces replaced by underscores. Then as the very last command in the relevant makefile section, insert a bash command to replace those underscores with spaces.

What if the filename is a mixture of underscores and spaces?

Escaping an escape character is not a new problem in programming. There are solutions :-)

"Premature generalization is the root of all evil."

Is there any clone of make that's aiming to address the issues with file name spaces?

Being incapable of handling spaces is a bug that's been marked Minor since 2002 - https://savannah.gnu.org/bugs/?712

(plus I find double quotation marks easier to read and write than escaping every space in a path)

Edit: https://stackoverflow.com/questions/66800/promising-alternat... (they aren't really clones tho)

I deal with this shape of problem quite a bit. After using scons and make in the past I recently tried using ninja, and it really works well.

Specifically, a python configure script using the ninja_syntax.py module. This seems like it's a bit more complicated, but has a lot of nice attributes.

File names with spaces should just work (unlike make). The amount of hidden complexity is very low (unlike make or SCons); all the complexity lives in your configure script. It's driven by a real, non-arcane language (unlike make). Targets are automatically rebuilt when their rules/dependencies change (unlike make).

It's more difficult to install than make, but only marginally.

Perhaps you just chose the wrong tool for the job. Just because you are able to do similar things with make, doesn't mean it is has to be suited to your chosen use case. It's a tool that was created with a specific purpose in mind, with specific constraints, and it works fine for thousands (I assume) of people every day. You can't blame it for not being a general-purpose programming language. Make isn't beyond building other tools that you can write yourself - and use in the very same makefiles - to assist in handling cases like this, however.

Spaces in filenames create troubles with almost every command line tool. cut(1), awk(1), find(1), xargs(1), what not. How do you quote them, do you need to use \0 as a separator instead, do other commands on the pipeline support \0 separators? What happens after a couple expansions, passing stuff from one script to another?

And what the heck happened on 31 dec 1999 that the world became a different place where suddenly people realised: there were these space things, quite useful they were, why don't we tuck them into every file name and URL and who knows what?

People have better things to do than dealing with these things.

> Spaces in filenames create troubles with almost every command line tool

Then that's a shortcoming which should be addressed with the tools, because humans everywhere use spaces in filenames.

For every command-line tool I make (Windows & Linux), I ensure it handles such trivial use-cases. I can't see why such a simple task is seemingly impossible to get done in GNU coreutils.

Very good of you indeed, but it's a hard task to retroactively change how a system and the greater community around it behaves and how standards like POSIX have defined field separation syntax for decades. I wouldn't mind if make supported spaces in filenames, but the thing is it's a bit late now and the problem is too unimportant to bother solving, frankly.

Reply on news.ycombinator.com