Extract file extension: Difference between revisions
→{{header|Fortran}}: Happily, no change is needed beyond adding the new trials.
(add "needs updating" template to 20 of the language entries) |
(→{{header|Fortran}}: Happily, no change is needed beyond adding the new trials.) |
||
Line 427:
=={{header|Fortran}}==
The plan is to scan backwards from the end of the text until a non-extensionish character is encountered. If it is a period, then a valid file extension has been spanned. Otherwise, no extension. Yet again the "no specification" on the possibility of shortcut evaluation of compound logical expressions prevents the structured use of a DO WHILE(L1 > 0 & TEXT(L1:L1)''etc'') loop because the possible evaluation of both parts of the expression means that the second part may attempt to access character zero of a text. So, the compound expression has to be broken into two separate parts.▼
▲The plan is to scan backwards from the end of the text until a non-extensionish character is encountered. If it is a period, then a valid file extension has been spanned. Otherwise, no extension. Yet again the "no specification" on the possibility of shortcut evaluation of compound logical expressions prevents the structured use of a DO WHILE(L1 > 0 & etc) loop because the possible evaluation of both parts of the expression means that the second part may attempt to access character zero of a text. So, the compound expression has to be broken into two separate parts.
The source incorporates a collection of character characterisations via suitable spans of a single sequence of characters. Unfortunately, the PARAMETER statement does not allow its constants to appear in EQUIVALENCE statements, so the text is initialised by DATA statements, and thus loses the protection of read-only given to constants defined via PARAMETER statements. The statements are from a rather more complex text scanning scheme, as all that are needed here are the symbols of GOODEXT.
Line 498 ⟶ 495:
WRITE (6,*) FEXT("/path/to.my/file")
WRITE (6,*) FEXT("file.odd_one")
WRITE (6,*)
WRITE (6,*) "Now for the new test collection..."
WRITE (6,*) FEXT("http://example.com/download.tar.gz")
WRITE (6,*) FEXT("CharacterModel.3DS")
WRITE (6,*) FEXT(".desktop")
WRITE (6,*) FEXT("document")
WRITE (6,*) FEXT("document.txt_backup")
WRITE (6,*) FEXT("/etc/pam.d/login")
WRITE (6,*) "Approved characters: ",GOODEXT
END</lang>
The output cheats a little, in that trailing spaces appear just as blankly as no spaces. The result of FEXT could be presented to TRIM (if that function is available), or the last non-blank could be found. With F2003, a scheme to enable character variables to be redefined to take on a current length is available, and so trailing spaces could no longer appear. This facility would also solve the endlessly annoying question of "how long is long enough", manifested in parameter MEXT being what might be a perfect solution. Once, three was the maximum extension length (not counting the period), then perhaps six, but now, what?
Line 508 ⟶ 513:
Approved 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz▼
Now for the new test collection...
.gz
.3DS
.desktop
Approved characters:
</pre>
Note that if FEXT were presented with a file name containing trailing spaces, it would declare no
=={{header|Go}}==
| |||