File extension is in extensions list: Difference between revisions
File extension is in extensions list (view source)
Revision as of 05:26, 4 September 2016
, 7 years ago→{{header|Fortran}}: Follow the new requirements.
(→{{header|zkl}}: update) |
(→{{header|Fortran}}: Follow the new requirements.) |
||
Line 232:
=={{header|Fortran}}==
The plan is to use the extractor function for file name extensions that was defined in another problem to obtain the extension's text, then use that text to index a character string of approved extensions. These are defined with the period included, but no extension's text can include a period - all start with a period and continue with letters or digits only - so the specification of a list of such items need not mess about with quotes and commas and so forth. The deed is done via function EXTIN(FNAME,LIST), but there is a lot of support stuff in the absence of an existing library to call upon. ▼
When the task was revised to include a # as a possible character in the file name extension part, the scan in FEXT that allowed only certain characters via GOODEXT required changing. One possibility was to increase the size of GOODEXT so as to encompass the three characters in ODDITIES, that includes a #. But it also includes a : (all this is from a different context) and in file names, under DOS, this character is special. So, all-in-all, it seemed better to retreat from exclusions and simply allow all characters, as per the original specification. This done, the function EXTIN that checked that the extension was one of a specified set seemed no longer restricted to file name extensions, so instead it became FOUND(TEXT,LIST) and the period, the only special character now, is used as the delimiter in LIST.
▲The plan is to use the extractor function for file name extensions that was defined in another problem to obtain the extension's text, then use that text to index a character string of approved extensions. These are defined with the period included, but no extension's text can include a period - all start with a period and continue with letters or digits only - so the specification of a list of such items need not mess about with quotes and commas and so forth. The deed is done via function EXTIN(FNAME,LIST), but there is a lot of support stuff in the absence of an existing library to call upon.
Petty details include the list employing capitals only, as the match is to not distinguish capital from lower case letters, so in the usual way the candidate extension's text is converted to capitals. The list could be subjected to UPCASE, but it is bad form to damage what might be a constant, and one possibly in read-only storage at that. An internal working copy could be made which would then be fed to UPCASE, except that this would be a waste on every invocation. A further trick involves appending a period to the candidate text so that for example ".JP" becomes ".JP." - otherwise a ".JP" would be found in the sequence ".JPG" which would be wrong, so as a result, the list of texts must have a period appended to its last entry, otherwise it would not be findable. Again, this could be done internally, via <code>INDEX(LIST//".",EXT(1:L)//".")</code> at a run-time cost.
Line 244 ⟶ 243:
A final annoyance is the presence of trailing spaces because character variables are of fixed size and so must be made "surely long enough" for the longest expectation. This may not cause trouble on output as spaces look just as blank as blank space, but they may well cause trouble in the internal tests. Thus integer function LSTNB reports the last non-blank, and so a test text can be presented with no trailing spaces, as in TEST(I)(1:LSTNB(TEST(I))) or similar. With Fortran 2003, there is a facility for redefining the sizes of character variables on-the-fly so that this problem can be evaded.
The MODULE protocol is employed for the convenience of not having to respecify the type of the functions in every calling routine, and also to facilitate the collection of types of characters. Otherwise, prior to F90 there would have to be various
CHARACTER*10 DIGITS !Integer only.
CHARACTER*11 DDIGITS !With a full stop masquerading as a decimal point.
Line 272 ⟶ 271:
CHARACTER*62 GOODEXT !These are all the characters allowed
EQUIVALENCE (CHARACTER(8),GOODEXT) !Starts with the first digit.
INTEGER MEXT !A fixed bound.
PARAMETER (MEXT = 28) !This
CONTAINS
INTEGER FUNCTION LSTNB(TEXT) !Sigh. Last Not Blank.
Line 319 ⟶ 318:
L1 = L2 !Starting at the end...
10 IF (L1.GT.0) THEN !Damnit, can't rely on DO WHILE(safe & test)
IF (
L1 = L1 - 1 !Well, that was a valid character for an extension.
GO TO 10 !So, move back one and try again.
END IF !Until
GO TO
END IF !Keep on moving back.
L1 = L2 !If we're here, no period was found.
Line 332 ⟶ 329:
END FUNCTION FEXT !Possibly, blank.
LOGICAL FUNCTION
CHARACTER*(*)
CHARACTER*(*) LIST !A sequence, separated by the periods. Like ".
CHARACTER*(
L = LSTNB(EXT) !Find its last non-blank.▼
IF (L.LE.0) THEN !A null text?
ELSE !Otherwise,
EXT(1:L) = TEXT(1:L) !A copy I can damage.
CALL UPCASE(EXT(1:L)) !Simplify.
END IF !The period can't be a character in an extension name.
END FUNCTION
END MODULE TEXTGNASH !Enough for this.
PROGRAM POKE
USE TEXTGNASH
INTEGER I,
INTEGER TESTS
CHARACTER*80 TEST(6) !A collection.▼
PARAMETER (TESTS = 12)
CHARACTER*(MEXT) EXT
DATA TEST/
1 "Picture.jpg",
2 "http://mywebsite.com/picture/image.png",
3 "myuniquefile.longextension",
4 "
5 "/path/to.my/file",
6 "file.odd_one"
7
8 "Mydata.tar.Gz",
PARAMETER (IMAGE = ".PNG.JPG.") !All in capitals, and ending with a . too.▼
9 "MyData.gzip",
o "MyData.7z.backup",
1 "Mydata...",
2 "Mydata"/
CHARACTER*(*) IMAGE !A sequence of approved texts, delimited by .
▲ PARAMETER (IMAGE = ".
WRITE (6,1) IMAGE
Line 365 ⟶ 371:
1 "File name",40X,"Extension",7X,"Test")
DO I = 1,
WRITE (6,2) TEST(I)(1:LFN),EXT(1:LEX),FOUND(EXT(1:LEX),IMAGE)
END DO▼
2 FORMAT (A48,A16,L) !Produces tidy columns, aligned right.
END</lang>▼
END DO !On to the next.
The previous results were when only "image" style files were approved. The approval is no longer so restrictive.
<pre>
To note file name extensions that are amongst .
File name Extension Test
http://mywebsite.com/picture/image
Mydata.a## .a## T
Mydata.tar.Gz .Gz T
MyData.gzip .gzip F
MyData.7z.backup .backup F
Mydata... . F
Mydata F
</pre>
The approval function relies on a period being special and that no extension contains one, as is stated in the specification. Thus, the likes of "tar.bz2" can't be added to the list of approved extensions. To do so would require some way of removing context dependency from within the list of approved tests, for instance by converting it to some sort of list of elements each of which has a length. So, if there were no more than 255 texts in a list, then character one would state their number, followed by the length of the first text (up to 255) then that number of characters, then the length of the second text, and so on. Then function FOUND would be fully general at the price of a more difficult initialisation of its list.
Similarly, the scan of a file name to find the extension part relies on no extension containing a period. If the caller were to determine the text of the extension (rather than using FEXT, which stops with the rightmost period) then whatever results could be presented to function FOUND without difficulty.
=={{header|Haskell}}==
| |||