Watch out for session names with extensions in it

[PaulWessel]

See #2082 for context. Do not allow session names with graphics file extensions, e.g.,

gmt begin map.pdf pdf

We may want to discuss what something like this should result in:

gmt begin map.png

With this fix we will produce map.pdf since no graphics format was given. Or what

gmt begin map.pdf png

should result in. Again, with this PR it will be map.png.

[seisman]

Why not keep it simple and consistent, i.e. gmt begin map.pdf pdf generates "map.pdf.pdf", gmt begin map.pdf png generates "map.pdf.png".

[anbj]

I agree with seisman. The name of the file (with or without extension) should not control anything. It's the specified format that should dictate this.

[joa-quim]

No, I don't agree. A *.png.pdf is a mistake for sure. And Windows can play very nasty tricks on these when it hides the known extensions. A shitty behavior that it learned from Macs. Then the user could be looking at a .png file that was actually being opened by Acrobat.

[PaulWessel]

Also, the reason we get the message that @abanbj reported has to do with psconvert. If -F is given a filename that already has an extension we chop it off, and of course that is not communicated back to gmt end show. I am pretty sure there are no good reasons to name files map.pdf.png is there? I mean, is this a valid naming scheme we should honor despite all the problems that come with it?

[PaulWessel]

Hence, the idea of allowing names like prefix.ext1.ext2 means we must either break backwards compatibility with psconvert -F or add a new option to not remove an extension if found.

I think this is a completely different case than making plots like bathymetry.grd.pdf which at least conveys the information that this is a grid based bathymetry map in PDF format. To me, bathymetry.pdf.png would then mean a bathymetry PDF map converted to PNG, but GMT does not do that (it converts from ps). So I see no logic here.

[anbj]

Making a *.png.pdf is not ideal, and I agree that in 99% of the cases it would be a mistake. About Windows hiding known extensions, I agree @joa-quim, it's a very shitty behaviour and I cant stand it. Still, I do not think GMT should worry about a users potential incompetence about this. I do see the point of not wanting to break backward compatibility.

[PaulWessel]

There is also the promise of modern mode to make things simple for users. Anyone who wants or needs to create such file names has the full power of classic mode to do whatever they please.

[seisman]

As for the Windows hiding known extensions, there is nothing we can do. A file "map.pdf" is displayed as "map", and users can't know if it's a PDF file or a batch script.

Although "map.png.pdf" is not a good name, I still think we should let users to choose the filename they like. For "gmt begin figname" and "gmt psconvert -F", the manpage clearly says that:

-Fout_name
Force the output file name. By default output names are constructed using the input names 
as base, which are appended with an appropriate extension. 
Use this option to provide a different name, but without extension. 
Extension is still determined automatically.

[PaulWessel]

Currently, psconvert will remove any extension from whatever is given to -F. Perhaps it should only remove an extension if it is the same as the final product? I.e., if psconvert -Tf -Fmap.pdf is given then .pdf should be stripped but if -Tg is given then it is not?

[seisman]

I would suggest not to strip any extensions. Users who use "gmt psconvert -Tf -Fmap.pdf" will get a file "map.pdf.pdf". If this is not what they want, then they should read the manual and correct their mistakes.

[PaulWessel]

Just so we are clear, this would be a backwards incompatible change to psconvert, but given the usage message above perhaps we can call it a bug and just "fix it".

[seisman]

Yes, that's exactly what I think.

[PaulWessel]

You OK with that @joa-quim ?

[joa-quim]

Like I've said before, I don't like it. file.pdf.pdf is 100% sure a mistake and if we can fix it for an incautious user, I don't see why we shouldn't keep doing it. This is different from file.png.pdf which is also a mistake but fixing it would move us to muddy ground, not to mention the work involved.
But I don't want to start another discussion.

[PaulWessel]

So I guess the issue is that we all agree that map.pdf.pdf is a user mistake. The question is whose job is it to fix it. @seisman feels that is the user's problem to fix, while @joa-quim feels we should help the user and prevent these sorts of errors. I do think the simplest case is to push this on the user instead of us wasting precious brain cells to fix other people's confusions. Given all the things we have on the plate, perhaps declaring the -F parsing a bug and stop stripping off extensions is the best solution. Any other solution runs into ambiguities (should map.png be OK if PDF is requested versus map.pdf when PDF is requested?) where we may or may not do what the user expects anyway.

So I propose we declare a -F bug and stop stripping things off. I can then remove the stripping that currently takes place in begin and figure as well.

[seisman]

totally agree.