Hi Tim,
>> The parsing of “555” to the integer 555 is done by >> org-babel-parse-header-arguments, and so can’t really be changed. > > I don't understand this. Why can't it be changed? Well, it can't be changed without changing org-babel-parse-header-arguments, which is quite a major change and I suspect may be a breaking change. Maybe it's fine? I just don't feel confident about this. > When I said disable base 10 values, what I meant was generate an error > if the value looks like it is base 10 i.e. does not have a leading o or > #o. This makes it clear it has to be specified as an octal value and > will alert users to this fact. This is all well and good, but the point I'm making is that since due to the current behaviour of org-babel-parse-header-arguments we can't distinguish between :tangle-mode (identity #o555) and :tangle-mode 365 putting this idea /into practice/ doesn't look like it will be easy. It's also worth noting that with regard to the recent changes that have been made, this is not a new issue. >> I think the ls-style is quite valuable for two reasons. It’s >> well-established thanks to ls, and is particularly good for >> understanding permissions at a glance. > > I would agree it is an established way to display the permissions > associated with a filesystem object, but disagree it is a well > established way to set such values - I know of no other tool which uses > this format. The driving motivation here is that while the tools which you mention do not use this for setting permissions (e.g. chmod), they are only used for /setting/ permissions. Since Org files aren't write-only, and occasionally we go back and look at what we've written :P I think allowing a format that is optimised for ease-of-reading instead of ease-of-writing makes some sense. It is in this respect that I think ls -l style is a good idea. > It is also not the same as the ls -l display (no object > type indicator). The ls -l also displays sticky bit, uid and gid. Does > your format also support setting these values (something which can be > done with the octal or symbolic formats) i.e. support s, S, t and T for > the 'executable' bit for user/group? Ah, I'm afraid that I'm not that up-together on sticky bits. I suspect that it's not just the ls -l style that will need tweaking. I'll read up on this in the next few days and update the ML. > Personally, I prefer the symbolic form as it is shorter and clear. I > find the ls -l form too easy to get wrong (especially with getting the > number of '-' correct). Isn't choice a great thing? :D In seriousness, this is exactly why I think it's worth providing these options. At least thinking back to when I started using Linux a few years ago I would have said the same thing about the octal form, and was completely unfamiliar with chmod. I expect different people to have different preferences with these three options, but for one of them to be something most people are happy with. >> Tim suggested that invalid forms should cause tangling to fail, but I feel >> this >> may be a bit much. Personally I’m inclined to either >> • warn, and don’t touch the file permissions (this is what currently occurs) >> • use a very conservative file permission (e.g. rw——-). > > I'm unsure on this. My concern is people may not notice the warning and > then be surprised later. Given the potential security issues, a later > surprise is something to be avoided even if it is inconvenient. With > respect to the default action to take, I would suggest we also need to > look at the default umask setting for the user and if that is more > restrictive, use that rather than some value like rw------- For all we > know, the user has set a specific umask for a valid reason and will be > surprised if emacs just ignores that to do what it wants (another > surprise to be avoided). > The user is not required to specify a mode. However, if they do and if > we cannot interpret what they have specified without ambiguity, we > should throw an error and cease processing. Making a guess as to what > they intended in this situation is IMO a big mistake. I don't see how using the default permissions is a potential security risk? Could it surprise the user, yes, but that seems unavoidable when the user is doing something invalid. > My only preference for "#o" over just "o" prefix is to clearly signal to > the user that it is an octal value and avoid the situation where you > might glance a value and see the leading 'o' as a '0', missing the point > it is an octal value not a decimal one. However, this seems like a low > risk, so I'm happy either way. Well, I've got "o" for now but that's not set in stone. With a lower case "o" I feel the risk for confusion with "0" is quite low (besides which a "0" prefix seems to be the C-style for octal anyway). All the best, Timothy