Hi Tim,
> I’ll let you (/the ML) know when I’ve taken a look at stiky bits, and whether
> I
> think I’m able to create something that works. My intuition is that if ls -l
> can
> properly represent sticky bits (and my rudimentary understanding is that it
> can)
> it should be fine for
Hi Tim,
Thanks for the way in which you’ve responded to my comments. I appreciate the
effort you’ve gone to to explain your views as opposed to simply saying you
disagree with some of my current thoughts :)
Tim Cross writes:
> My suggestion is simply to look at the value and if it is not a
Timothy writes:
> 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,
Timothy,
> Just a quick note (see my long recent reply to Tim where I expand on this
> more),
> but this isn’t new behaviour (isn’t actually affected by my recent changes)
> and
> my concerns are with the viability of the necessary changes rather than
> whether
> this would be good (we are of
Hi Greg,
> i’d push back, even here, on allowing decimal. file modes are bit
> masks. to me, offering a way to set a bit mask via a *decimal* value
> seems a mistake.
Just a quick note (see my long recent reply to Tim where I expand on this more),
but this isn’t new behaviour (isn’t actually
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
hi, Timothy,
> I’ve just pushed three commits that
> 1. Add “o555” as an octal shorthand
> 2. Perform a simple check that integer modes are valid*
> 3. Make the ls-style regex stricter
> ...
> * For example, “:tangle-mode 755” will now produce the warning:
> “1363 is not a valid file mode
Timothy writes:
> * For example, “:tangle-mode 755” will now produce the warning:
> “1363 is not a valid file mode octal. Did you give the decimal value 755 by
> mistake?”. Maybe it would be worth adding “if so try o755” or similar?
I think that warning will be confusing for users. They
Timothy writes:
> The parsing of “555” to the integer 555 is done by
> org-babel-parse-header-arguments, and so can’t really be changed. For a simple
> octal notation our best bet is adding non-digit characters so it is left as a
> string, e.g. “o555”.
I don't understand this. Why can't it be
On Sat, Nov 20, 2021 at 10:50:40PM +0800, Timothy wrote:
> Hi Thomas (& co.),
[...]
> Thanks. It helps that this list is fairly friendly to begin with :)
Friendly lists are made of friendly people, and there, your contribution
is... special.
> * For example, “:tangle-mode 755” will now produce
Hi Thomas (& co.),
>> […] I’m thinking either “o555” or “#o555” would be a good improvement over
>> “(identity #o555), but am open to other suggestions.
>
> That’s reasonable. I’d even tend to disallow decimal. In usage, it’s too
> exotic and the potential for someone entering “just a number”
On Sat, Nov 20, 2021 at 04:08:16PM +0800, Timothy wrote:
> Hi Tom, Tim, Thomas, and Greg,
[...]
> • a shorthand for octal
> • ls-style
> • chmod-style
> I think this small collection of distinct and simple input methods isn’t
> overly
> clever or complex, and feel that it strikes the right
Hi Tom, Tim, Thomas, and Greg,
Thank you all for your thoughts. I’ll try to respond to all the main points
raised below.
First off, in case it wasn’t clear in my earlier email when I said “#o555 works”
or the like I was being lazy and really meaning “(identity #o555)” works.
The parsing of
> Timothy writes:
> I would just accept two formats, both being strings with either "o400"
> (or perhaps "#o400") and "u+rwx" symbolic form and anything else
> generates an error (a hard error, not a warning i.e. stop processing,
> don't tangle).
+1. (i'm neutral w.r.t. "o400" vs. "#o400".)
On Sat, Nov 20, 2021 at 03:31:16AM +1100, Tim Cross wrote:
>
> Timothy writes:
>
> > Hi All,
> >
> > I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755
[...]
> Thanks for your work on this. I am a little concerned we are making a
> rod for our back by trying to make
Timothy writes:
> Hi All,
>
> I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755
> doesn’t actually work as expected. I assumed 755 would be passed as a string
> but
> org-babel-parse-header-arguments actually turns it into an integer, just like
> (identity #o755).
Hi Timothy,
The confusion with 755 and "755" could lead to security issues in
cases like 600 vs "600" vs #o600. The need to protect against the 600
case is fairly important, however I don't think there is anything we
can do about it, because someone might want to enter their modes as
base 10
Hi All,
I thought I’d checked for this, but I’ve just noticed that :tangle-mode 755
doesn’t actually work as expected. I assumed 755 would be passed as a string but
org-babel-parse-header-arguments actually turns it into an integer, just like
(identity #o755). Obviously 755 != #o755 and so this
Hi All,
This has just been pushed as described in fa97f9a39.
See some tests I performed before pushing below.
#+begin_src text :tangle-mode (identity #o345) :tangle t1.txt
this works
#+end_src
#+begin_src text :tangle-mode 433 :tangle t2.txt
this works
#+end_src
#+begin_src text :tangle-mode
On 05/10/2021 21:45, Timothy wrote:
Indeed, I’ve basically supported every form I could think of. I’m currently
inclined to cut it down to:
• 755
• “rwxrw-r–” (`ls -l’ style)
• chmod style with `org-babel-tangle-default-mode’ and
`file-modes-symbolic-to-number’
Maybe with (if anybody says
Hi Jeremy,
> I think this is a good idea and don’t see any problems (or other
> suggestions) with the proposed formats.
>
> The existing (identity #o0755) will still function, correct?
> i.e. backward compatibility.
It should yes. I’ll double check before I actually push the commit.
All the
On Tue, Oct 05, 2021 at 10:45:59PM +0800, Timothy wrote:
> Hi Everyone,
>
> It feels like we’re near a patch that would be good to merge. I would very
> much
> like to get feedback on what I proposed in my reply to Tom though (see below).
OK. Since I made some noises, I feel compelled to feed
Timothy writes:
> It feels like we’re near a patch that would be good to merge. I would very
> much
> like to get feedback on what I proposed in my reply to Tom though (see below).
>
>> Maybe with (if anybody says they would like this)
>> • #o755 (elisp octal)
>> • 0755 (C octal)
>> • “rwx” =
Hi Everyone,
It feels like we’re near a patch that would be good to merge. I would very much
like to get feedback on what I proposed in my reply to Tom though (see below).
>> That said, reducing the number of forms as Eric suggests would
>> be a happy medium.
>
> Indeed, I’ve basically
Hi Tom,
Thanks for going through the replies so far and refining your thoughts.
> *snip a whole bunch of comments*
I think I’m of the same mind as you that if we try to mentally separate Org the
markup format and Org the emacs mode, the format should not specify the
interpretation of the
> I'd like to understand these objections better. Aren't you overstating
what is at issue?
Yes, after hitting send I realized I overstated my position a bit.
In the meantime the comments in this thread are encouraging,
however I have finally figured out what I was really trying to say.
tl;dr
On Fri, Oct 01, 2021 at 11:05:17AM +0100, Eric S Fraga wrote:
[...]
> > I would also tend to only support something like "#o755" and forbid
> > "755" as well as "0755", just to be more explicit and to avoid
> > misinterpretation.
>
> Here I disagree; again, in the manual, the notation used, as
> BTW: Security-wise I would argue to even forbid the integer case.
Completely agree with this. If you look at the chmod(1) man page, only
symbolic and octal cases are described. These are the options most
people will be comfortable with as a result.
> I would also tend to only support
Tom Gillespie writes:
> I strongly oppose this patch. It adds far too much complexity to the
> org grammar. Representation of numbers is an extremely nasty part of
> nearly every language, and I suggest that org steer well clear of
> trying to formalize this.
I'd like to understand these
Timothy writes:
> Thank you for considering potential security implications
BTW: Security-wise I would argue to even forbid the integer case. From
my view next to nobody uses and is used to the decimal codes of file
modes. So this decimal integer representation is the most error prone,
I would
Hi Tom,
Thanks for giving me your thoughts on this. I have a few thoughts in response :)
> I strongly oppose this patch. It adds far too much complexity to the
> org grammar. Representation of numbers is an extremely nasty part of
> nearly every language, and I suggest that org steer well clear
I strongly oppose this patch. It adds far too much complexity to the
org grammar. Representation of numbers is an extremely nasty part of
nearly every language, and I suggest that org steer well clear of
trying to formalize this. With an eye to future portability I suggest
that no special cases be
Hello,
Currently, the only way to set a file mode when tangling seems to be
:tangle-mode (identity #o755)
In a [prior thread], Jeremy proposed that :tangle-mode should convert octal
number strings to the required decimal form. I think we should go further, and
so have prepared the attached
33 matches
Mail list logo
