Bug#473156: [checks/scripts] dash now supports $((cnt+1))
Package: lintian Version: 1.23.46 Severity: wishlist Tags: patch Hi, dash (finally) gained support for the shell arithmetic construct $((var +1)) with the upload of 0.5.4-3 in December 2007 (see #329025). As lenny contains a version of dash with the support, I've attached a patch removing the corresponding test from the bashisms section of checks/scripts. Regards, Adam --- scripts.orig 2008-03-25 19:04:56.0 + +++ scripts 2008-03-28 18:15:03.0 + @@ -572,7 +572,6 @@ '(\|\)\s*((-|\d+)[^\s;|\)\`]|[^-\d])', # should be word 21 '\[\[(?!:)', # alternative test command '(?:^|\s+)select\s+\w+', # 'select' is not POSIX - '\$\(\([A-Za-z]', # cnt=$((cnt + 1)) does not work in dash '(?:^|\s+)echo\s+-e',# echo -e '(?:^|\s+)exec\s+-[acl]',# exec -c/-l/-a name '(?:^|\s+)let\s', # let ...
Bug#473156: [checks/scripts] dash now supports $((cnt+1))
Adam D. Barratt [EMAIL PROTECTED] writes: Package: lintian Version: 1.23.46 Severity: wishlist Tags: patch dash (finally) gained support for the shell arithmetic construct $((var +1)) with the upload of 0.5.4-3 in December 2007 (see #329025). As lenny contains a version of dash with the support, I've attached a patch removing the corresponding test from the bashisms section of checks/scripts. dash is not the metric for bashisms, though. If it's not in POSIX and isn't listed as an exception in Policy 10.4, it's not allowed for /bin/sh scripts. Do you think we should add this as an additional exception? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473156: [checks/scripts] dash now supports $((cnt+1))
On Fri, 2008-03-28 at 11:31 -0700, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: [...] dash (finally) gained support for the shell arithmetic construct $((var +1)) with the upload of 0.5.4-3 in December 2007 (see #329025). As lenny contains a version of dash with the support, I've attached a patch removing the corresponding test from the bashisms section of checks/scripts. dash is not the metric for bashisms, though. If it's not in POSIX and isn't listed as an exception in Policy 10.4, it's not allowed for /bin/sh scripts. I realise that. :-) The comment against the check does say doesn't work in dash, although I realise that's merely informative. Do you think we should add this as an additional exception? As far as I can see, it *is* in POSIX, which is what persuaded Herbert to (albeit slowly) add it to dash. quote 2.6.4 Arithmetic Expansion Arithmetic expansion provides a mechanism for evaluating an arithmetic expression and substituting its value. The format for arithmetic expansion shall be as follows: $((expression)) [...] Next, the shell shall treat this as an arithmetic expression and substitute the value of the expression. The arithmetic expression shall be processed according to the rules given in Arithmetic Precision and Operations , with the following exceptions: * Only signed long integer arithmetic is required. [...] If the shell variable x contains a value that forms a valid integer constant, then the arithmetic expansions $((x)) and $(($x)) shall return the same value. /quote My reading of the above is that $((var+1)) is valid and that the comment against the check was correct - i.e. it's not a bashism at all, but was being checked for simply because dash did not correctly support the syntax despite it being permitted by POSIX with no extensions. As a further data point, posh supports both $((var+1)) and $((var=1)). Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473156: [checks/scripts] dash now supports $((cnt+1))
Adam D. Barratt [EMAIL PROTECTED] writes: As far as I can see, it *is* in POSIX, which is what persuaded Herbert to (albeit slowly) add it to dash. Oh! Then the comment now makes sense to me, and by all means we should remove this check. Thank you very much for this; I hadn't realized that was a standard feature. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473156: [checks/scripts] dash now supports $((cnt+1))
On Fri, 2008-03-28 at 11:59 -0700, Russ Allbery wrote: Adam D. Barratt [EMAIL PROTECTED] writes: As far as I can see, it *is* in POSIX, which is what persuaded Herbert to (albeit slowly) add it to dash. Oh! Then the comment now makes sense to me, and by all means we should remove this check. Thank you very much for this; I hadn't realized that was a standard feature. It wasn't. Having just checked, SUS2 only requires $(($var+1)); $((var +1)) is an SUS3 addition. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lintian tag classification (was: Bits from the Lintian maintainers)
Jordà Polo [EMAIL PROTECTED] writes: I'm thinking of working on it as suggested by Marc Brockschmidt's proposal[1] for Google's Summer of Code. I think that would be fantastic! I'm sorry about the delay in responding; I've been really busy with my day job for the past couple of weeks. The goals are clear and I don't think there is a lot of room for creativity, but I still would like to know your thoughts about how it should be implemented. Basically, my initial idea is to make it possible to use a comma-separated list of keywords in Type:, instead of using «error», «warning» or «info» only. (Keywords may include a namespace as in «severity::error» or «certainty::wild-guess», depending on how the final classification looks like.) This way it would be easy to include more information later if needed (such as «origin::policy», etc.). But does it make sense, or you think this breaks the purpose of Type: and new headers must be created for each category? I think that you will find it easier to do the work incrementally if you keep Type as-is and add a new header containing this information. We can then run Lintian in either mode and compare the results for a while before retiring the old classification system and rebasing it on the new tags. Otherwise, it becomes a single flag-day change, and those are always harder to pull off. Otherwise, this is more general than I had been planning but still seems fundamentally sound. I think it's worth considering, given that we already have a field syntax where it's very easy to add more fields, whether it makes sense to use keywords instead of just adding more fields. In other words, rather than having: Type: severity::error, certainty::wild-guess, origin::policy you could have: Severity: error Certainty: wild-guess Origin: policy and use more of the existing parsing infrastructure without having to handle the keywords separately. Taking a step back from the specific details, I see this work as having three basic steps. This is just my view on it, though, and you may want to do it differently. * Design and implement a new output format based on this classification rather than the existing E/W/I classification, along with the code to read the new classification information from the checks/*.desc files and maintain the internal data structures. There should be new options to specify the severity, certainty, and origins that one is interested in seeing and the output should be filtered accordingly. Lintian's exit status may also require some attention. * Implement a mapping from the new classifications to the old E/W/I so that we can retire the existing Type while maintaining a backward-compatible interface. * Go through each tag and classify it according to the new system. This is the part that requires the most tedious effort, but the work can be shared and can be done incrementally as long as the new code can handle tags that have not yet been classified in the new system. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Lintian tag classification
Jordà Polo [EMAIL PROTECTED] writes: My view isn't that different. A fourth step I also thought about is enhancing lintian.debian.org to support the new classification, but it probably isn't a basic step. Yes, that's a good point. Currently, there are several places where the type is used in that code: * We gather statistics for QA purposes that includes a count of errors and warnings (separately) for each package. * There are two views of the maintainer page, one of which showing all of the tags and the other only showing errors and warnings. When you change the representation of tag severities, there are a lot of little things like that which will need tweaking. Another is the colorization of tags, which currently is done only based on the E/W/I status. It would be particularly cool to support using JavaScript or something similar to selectively hide and show tags from different sources, certanties, or severities, but that verges on a whole additional project. :) Thanks for your comments, they are really appreciated. You helped me solve a few misunderstandings I had, and made me realize about some flaws in my proposal. Absolutely. I'm very happy to answer any questions. Please feel free to ping me if mail goes without an answer for a few days; sometimes mail gets buried. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
