[aur-general] Backslash to split lines in `depends` array
Hi, I was trying to update my AUR packages with `aura` [1] † and get the following error: aura >>= Determining dependencies... aura >>= Dependency checking failed for these reasons: The dependency `\` could not be found. You may need to search for a package to satisfy it. This is due to the following lines in `octave-hg` [2] PKGBUILD: depends=('fftw>=3.2.2' 'curl' 'fltk' 'hdf5' 'glpk' 'arpack' 'gl2ps' \ 'qrupdate' 'qscintilla' 'qhull' 'graphicsmagick' 'java-environment') The problem doesn't seem to appear with `yaourt` [3] . So before filling a bug request to `aura`, I wanted to be sure that it is allowed/common to use `\` to split lines in the `depends` array? If it is not the case, I will post a comment on the `octave-hg` AUR page to ask to remove the backslash. † Also tested with `aura-git`, the problem still exists. [1] https://aur.archlinux.org/packages/aura/ [2] https://aur.archlinux.org/packages/octave-hg/ [3] https://aur.archlinux.org/packages/yaourt/ Best regards, Fabien
Em 03/11/2013 10:29, Fabien Dubosson escreveu:
Hi,
I was trying to update my AUR packages with `aura` [1] † and get the following error:
aura >>= Determining dependencies... aura >>= Dependency checking failed for these reasons: The dependency `\` could not be found. You may need to search for a package to satisfy it.
This is due to the following lines in `octave-hg` [2] PKGBUILD:
depends=('fftw>=3.2.2' 'curl' 'fltk' 'hdf5' 'glpk' 'arpack' 'gl2ps' \ 'qrupdate' 'qscintilla' 'qhull' 'graphicsmagick' 'java-environment')
The problem doesn't seem to appear with `yaourt` [3] . So before filling a bug request to `aura`, I wanted to be sure that it is allowed/common to use `\` to split lines in the `depends` array?
If it is not the case, I will post a comment on the `octave-hg` AUR page to ask to remove the backslash.
† Also tested with `aura-git`, the problem still exists.
[1] https://aur.archlinux.org/packages/aura/ [2] https://aur.archlinux.org/packages/octave-hg/ [3] https://aur.archlinux.org/packages/yaourt/
Best regards, Fabien
Remove '\'.
Den 03-11-2013 13:29, Fabien Dubosson skrev:
[...] So before filling a bug request to `aura`, I wanted to be sure that it is allowed/common to use `\` to split lines in the `depends` array?
For some more in-depth information than Rafael's commanding comment: 1) the \ character followed by a newline is used for breaking up long lines in (ba)sh code. The $depends array is thus perfectly valid bash, and I would file a bug report against aura to either make it not error - or at least change it to a warning, since: 2) there's no need to escape the newline in the $depends array, as newlines will just be treated like other whitespace until the array definition is ended by the ")" character, thus I would *also* do as Rafael "suggested" and ask the octave-hg to remove the backslash. -- Frederik "Freso" S. Olesen <http://freso.dk/>
This is a bug in aura's array parsing logic, which is in Bash/Parser.hs line : array :: Parser [BashString] array = concat . catMaybes <$> array' <?> "valid array" where array' = char '(' *> spaces *> manyTill single' (char ')') single' = (Nothing <$ comment <* spaces) <|> (Just <$> single) ...and is missing backslash ('\\') support and is overly simplistic. See for comparison the command parser in the same file (which has backslash support): command :: Parser Field command = spaces *> (Command <$> many1 commandChar <*> option [] (try args)) where commandChar = alphaNum <|> oneOf "./" args = char ' ' >> unwords <$> line >>= \ls -> case parse (many1 single) "(command)" ls of Left _ -> fail "Failed parsing strings in a command" Right bs -> return $ concat bs line = (:) <$> many (noneOf "\n\\") <*> next next = ([] <$ char '\n') <|> (char '\\' *> spaces *> line) On Sun, Nov 3, 2013 at 8:09 AM, Frederik "Freso" S. Olesen < freso.dk@gmail.com> wrote:
Den 03-11-2013 13:29, Fabien Dubosson skrev:
[...] So before filling a
bug request to `aura`, I wanted to be sure that it is allowed/common to use `\` to split lines in the `depends` array?
For some more in-depth information than Rafael's commanding comment: 1) the \ character followed by a newline is used for breaking up long lines in (ba)sh code. The $depends array is thus perfectly valid bash, and I would file a bug report against aura to either make it not error - or at least change it to a warning, since: 2) there's no need to escape the newline in the $depends array, as newlines will just be treated like other whitespace until the array definition is ended by the ")" character, thus I would *also* do as Rafael "suggested" and ask the octave-hg to remove the backslash.
-- Frederik "Freso" S. Olesen <http://freso.dk/>
Thanks all for your replies, I posted a comment to `octave-hg` AUR page to ask to remove it. I also noticed that the problem is already known in aura [1] and a pull request is waiting [2]. I must have checked here before. [1] https://github.com/fosskers/aura/issues/152 [2] https://github.com/fosskers/aura/pull/164 Kind regards, Fabien 2013/11/3 Ido Rosen <ido@kernel.org>
This is a bug in aura's array parsing logic, which is in Bash/Parser.hs line :
array :: Parser [BashString] array = concat . catMaybes <$> array' <?> "valid array" where array' = char '(' *> spaces *> manyTill single' (char ')') single' = (Nothing <$ comment <* spaces) <|> (Just <$> single)
...and is missing backslash ('\\') support and is overly simplistic. See for comparison the command parser in the same file (which has backslash support):
command :: Parser Field command = spaces *> (Command <$> many1 commandChar <*> option [] (try args)) where commandChar = alphaNum <|> oneOf "./" args = char ' ' >> unwords <$> line >>= \ls -> case parse (many1 single) "(command)" ls of Left _ -> fail "Failed parsing strings in a command" Right bs -> return $ concat bs line = (:) <$> many (noneOf "\n\\") <*> next next = ([] <$ char '\n') <|> (char '\\' *> spaces *> line)
On Sun, Nov 3, 2013 at 8:09 AM, Frederik "Freso" S. Olesen < freso.dk@gmail.com> wrote:
Den 03-11-2013 13:29, Fabien Dubosson skrev:
[...] So before filling a
bug request to `aura`, I wanted to be sure that it is allowed/common to use `\` to split lines in the `depends` array?
For some more in-depth information than Rafael's commanding comment: 1) the \ character followed by a newline is used for breaking up long lines in (ba)sh code. The $depends array is thus perfectly valid bash, and I would file a bug report against aura to either make it not error - or at least change it to a warning, since: 2) there's no need to escape the newline in the $depends array, as newlines will just be treated like other whitespace until the array definition is ended by the ")" character, thus I would *also* do as Rafael "suggested" and ask the octave-hg to remove the backslash.
-- Frederik "Freso" S. Olesen <http://freso.dk/>
On 3 Nov 2013 13:44, "Fabien Dubosson" <fabien.dubosson@gmail.com> wrote:
Thanks all for your replies, I posted a comment to `octave-hg` AUR page to ask to remove it.
In my opinion, it is not the maintainer's problem if $aurhelper cannot parse the PKGBUILD. The only thing that the maintainer needs to make sure can parse it, is makepkg.
On 3 November 2013 20:29, Fabien Dubosson <fabien.dubosson@gmail.com> wrote:
The problem doesn't seem to appear with `yaourt` [3] . So before filling a bug request to `aura`, I wanted to be sure that it is allowed/common to use `\` to split lines in the `depends` array?
For an even more simplistic understanding: foo=(one \ two) is understood as: foo=(one two) as much as: foo=(one two) PKGBUILDs are simply Bash scripts, so it's not about what is allowed in the 'depends' array, but what is valid Bash. The '\' is redundant but valid. The wrapper you're using is simply not doing a perfect job of parsing Bash, but it's not that big of a deal. Also note that use of single quotes protects interpretable characters (try versioned depends without quotes), while double quotes allow variable expansion. Using either type of quoting throughout an array is a stylistic choice. At the end of the day, the lesson learnt here is to use supported tools, or at least an unsupported one that has stood the test of time (if you don't want to bother troubleshooting functional glitches). -- GPG/PGP ID: C0711BF1
participants (6)
-
Fabien Dubosson
-
Frederik "Freso" S. Olesen
-
Ido Rosen
-
Rafael Ferreira
-
Rashif Ray Rahman
-
WorMzy Tykashi