-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Escaping characters kept during the whole toolchain #121
Comments
That being said, in package
we get:
which should be a valid version, in which case our version parser in our symbolic utility |
Yes that is a valid version, since about 10 years (when we added the "~"
character to the syntax of version strings).
Just to be sure that this is not due to an antediluvian version of dpkg:
can you please try
dpkg --validate-version 6.25.1-1~ && echo OK
on the machine where you have observed that error ?
--
Ralf Treinen
Institut de Recherche en Informatique Fondamentale
Pôle Preuves, Programmes et Systèmes
Université de Paris
http://www.irif.fr/~treinen/
|
How stupid can I be. There was indeed no dpkg on the machine. Forget that second point… What surprises me a bit more is that |
a machine without dpkg, how is that possible?
maybe availability of dpkg could be checked at startup of the tool.
--
Ralf Treinen
Institut de Recherche en Informatique Fondamentale
Pôle Preuves, Programmes et Systèmes
Université de Paris
http://www.irif.fr/~treinen/
|
The "\" character is not allowed in debian version strings.
Aren't these "\" simply interpreted by the shell ?
--
Ralf Treinen
Institut de Recherche en Informatique Fondamentale
Pôle Preuves, Programmes et Systèmes
Université de Paris
http://www.irif.fr/~treinen/
|
My arch linux laptop.
Or at least dynamically when handling the return value of the call to dpkg (if the return code is 127 for instance). |
On the given example, they are here to protect the special character |
On Fri, Feb 21, 2020 at 08:01:01AM -0800, Nicolas Jeannerod wrote:
> The "\" character is not allowed in debian version strings. Aren't these "\" simply interpreted by the shell ?
On the given example, they are here to protect the special character `~` (although it is not so special at that place, so I don't know), and they disappear during the expansion phase of the Shell. But we don't have an expansion phase *per se*, so we can either consider that it should be removed in the parsing of CST words (and in Morbig) or in the expansion (emulated by the conversion, or in the evaluation semantics of Colis).
The implementation uses Sys.command to execute dpkg with some arguments,
and Sys.command calls the shell.
…-Ralf.
--
Ralf Treinen
Institut de Recherche en Informatique Fondamentale
Pôle Preuves, Programmes et Systèmes
Université de Paris
http://www.irif.fr/~treinen/
|
Take package
libkf5xmlrpcclient5
. Here is its preinst:Now run colis-language on this script. You get the following in the logs:
This is the symbolic version of the utility
dpkg-maintscript-helper
complaining that5.61.0-1\~\~
is not a valid version number. And this is correct, as the version number that would actually reachdpkg-maintscript-helper
in the original script is5.61.0-1~~
which is a valid version number.Now this comes from the fact that Morbig, in its parser of words, keeps the backslashes. It has already been mentionned in colis-anr/morbig#110, but this issue has not gotten any answer yet, so I don't know whether it is a bug that should be fixed or a feature. In the first case, the bug should be fixed in Morbig. In the second case, the conversion to Colis needs to take that into account.
@yurug Which is it?
The text was updated successfully, but these errors were encountered: