0000573: Please add '+' to the portable filename character set

Notes
(0001256) eblake (manager) 2012-06-14 15:31	Part of this proposal should be considering the inclusion of a new option to pathchk; -p should always target the current standard (so for Issue 7, -p rejects '+', but for Issue 8, -p would allow '+'; similar for a leading '+' with -P), a new option would make it possible even for an Issue 8 pathchk to validate whether the name complies with Issue 7.

(0001259) psmith (developer) 2012-06-14 17:35	One issue that needs to be addressed is how variable names ENDING with special characters will interact with assignment operators that may begin with special characters. For example "+" is perfectly valid in variables in GNU make today, however if you write "C++=g++" this is interpreted to be "C+ += g++", not "C++ = g++", because "+=" is a valid assignment operator. There may be more special operators defined by other versions of make and I don't want to restrict this even for GNU make. Perhaps we need to add a requirement that either variables must end with a alphanumeric character or there must be whitespace between the variable and the assignment operator. Or something like that.

(0001264) joerg (reporter) 2012-06-16 13:14 edited on: 2012-06-16 13:15	Other make implementations require one or more space characters before "+=". I was not even awave of that gmake seems to behave this way. For this reason, all portable make files have white space before the "+=". If someone for some reason would like to implement "-=" as operator, he would also need to require a space before this new operator. I have no idea from which make implementation gmake copied this feature, but SunPro make introduced it in spring 1986 and since then has the following content in the manual page: += When used in place of =, appends a string to a macro definition (must be surrounded by white space, unlike =).

(0001267) psmith (developer) 2012-06-18 19:30	It doesn't matter to me which make had what first or whether features were copied or co-invented. I am requesting that any new wording in the standard allowing new characters in variable names should be clear about what happens in situations where this creates ambiguities with assignment operators, and that it does not invalidate GNU make's current behavior as being non-compliant.

(0001268) joerg (reporter) 2012-06-21 11:59	The following locations contain the term portable filename character set: 1856 3.189 Group name 2189 3.275 Portable character set 2196 3.266 Portable filename charcter set 2911 4.7 filename portability 4072 charclass 5666 LOGNAME 42412 mkdtmp() 80991 chown() 94296 m4/mkstemp 98969 pathchk 99287 pax 109681 uucp 109918 uudecode 110234 uux 115106 Rationale for base definitions 115626 A.4.7 Filename Portability 111600 Environment/LOGNAME

(0001695) shware_systems (reporter) 2013-08-02 22:30	> It seems that the plus sign was not in the portable filename character set, because DOS 8.3 names did not allow it. Today, filesystems are less picky with filenames and it would help to add characters, in special as other definitions in the standard are derived from the portable filename character set. > This request is related to issue #373. One issue, though more systems are tolerant of them, the current EFI BIOS versions many hardware implementations are based upon uses FAT32 as its native file system, which still has the 8.3 restrictions, so any implementation built for those machines will have to take into account the possibility that the restriction holds if the partition for the BIOS gets mounted. I'd like to see this too, but on that basis I recommend rejecting it - at least until EFI switches to something like ISO-9660 (CD-ROM) for its boot partition format.

(0001696) shware_systems (reporter) 2013-08-02 22:58	As to the issue of whether punctuation besides "_" should be allowed in environment or shell variable identifiers, I'd be more open to defining an operator like "v'" & "V'" (for wide chars), like C's "L'", to be used when such names would have to be created or disambiguated from other punctuation as operators. It could even use the '' convention to include single quotes inside those names as apostrophes. This would be for Version 8, though, as a Future Direction for shell and make, and similar utilities. I don't believe it would break any existing scripts.

(0001710) shware_systems (reporter) 2013-08-11 15:24	Also, the relation to #373, I looked at the code for gmake. It permits dashes as first characters and internal characters, but only when the macro definition is not at first position of the command line. Then it strips it off as an operator like POSIX make, so --Var-name = would be needed, not just -Var-name =. It also makes special checks that for the [macro=value...] command line option only var names that start with letter or _, and letter,_,digit following up to = to stay exported. Variables with +,., or - are "local only". So while .,+,- are a permitted extension, it's restricted use and POSIX macro names didn't list any restrictions defined as is, that I saw. Not allowing '-' as a leading char is a safety feature too, in that within a makefile they're used directly so can be easy enough to forget that the dereference $() or ${} is needed when using them as shell or app invocation parameters. So, if they are to be added I believe the best compromise is that initial char will be letter or '_'; internal chars may be letter, digit, punct that isn't going to be confused as operators, shell operators, or invocation switches incompatible with getopt() in that parse position, such as '-' and '_', but not '='; and end with letter, digit or '_'. A list of which chars are known to create conflicts, like '=', would be useful, perhaps. Verbiage such as: "If a char of class punct other than '_' is used in a macro name, it is recommended that a SP char precede any operators for maximum portability, as differences of interpretation by implementation-specific parsing conventions may not recognize intended end of name otherwise." I believe gmake does a one-char lookahead if a possible operator detected, which could be why C++= parses as C+ +=, not 'longest-match' parsing as expected of BREs and EREs that would produce C++ =. [-v('\|")macro=data('\|")...] and -V('\|") are available as command line options, for special char macro names that should be exported, presuming all chars in definition are accepted by put/setenv(). The explicit switch and quoting required I think makes it compatible with everything that isn't using a -v or -V switch now.

(0003077) dannyniu (reporter) 2016-02-18 04:23	I agree with note 0001695, but for some different reasons. The '+' the plus sign is a special character in URLs, which means it'll have to be represented differently from itself in order to represent itself. Also I think 'portable' in this case means both forward and backward compatibility, it means greatest common divisor, so newer versions' PFCS == older versions' PFCS (PFCS = portable filename character set).

(0005847) geoffclare (manager) 2022-06-09 15:33	This was discussed in the June 9th, 2022 teleconference. In view of the potential problems that adding '+' might cause, as raised in earlier bug notes, it was decided that this bug should be rejected.

Issue History
Date Modified	Username	Field	Change
2012-05-31 16:41	joerg	New Issue
2012-05-31 16:41	joerg	Status	New => Under Review
2012-05-31 16:41	joerg	Assigned To	=> ajosey
2012-05-31 16:41	joerg	Name	=> Jörg Schilling
2012-05-31 16:41	joerg	Section	=> 3.276
2012-05-31 16:41	joerg	Page Number	=> 77
2012-05-31 16:41	joerg	Line Number	=> 2198
2012-06-01 10:07	geoffclare	Project	2008-TC1 => 1003.1(2008)/Issue 7
2012-06-14 15:20	eblake	Relationship added	related to 0000373
2012-06-14 15:31	eblake	Note Added: 0001256
2012-06-14 17:35	psmith	Note Added: 0001259
2012-06-16 13:14	joerg	Note Added: 0001264
2012-06-16 13:15	joerg	Note Edited: 0001264
2012-06-18 19:30	psmith	Note Added: 0001267
2012-06-21 11:59	joerg	Note Added: 0001268
2012-08-03 19:36	eblake	Relationship added	related to 0000251
2012-08-03 22:37	eadler	Issue Monitored: eadler
2013-08-02 22:30	shware_systems	Note Added: 0001695
2013-08-02 22:58	shware_systems	Note Added: 0001696
2013-08-02 22:59	shware_systems	Issue Monitored: shware_systems
2013-08-11 15:24	shware_systems	Note Added: 0001710
2016-02-18 04:23	dannyniu	Note Added: 0003077
2022-06-09 15:33	geoffclare	Interp Status	=> ---
2022-06-09 15:33	geoffclare	Note Added: 0005847
2022-06-09 15:33	geoffclare	Status	Under Review => Closed
2022-06-09 15:33	geoffclare	Resolution	Open => Rejected

Aardvark Mark IV