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

XDG config envs do not accept quoted paths #2062

Closed
ingwinlu opened this Issue Jun 10, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@ingwinlu
Contributor

ingwinlu commented Jun 10, 2018

Steps to Reproduce the Problem

The command /home/jenkins/workspace/libelektra_PR-2060-UC533EJXFEGIMCPXROAS5K3DQGSNDLWE3TI7WV4NENQDLGK2UB4A@3/build/bin/kdb get failed while accessing the key database with the info:
 Sorry, 8 warnings were issued ;(
 Warning (#100):
	Description: environment variable is not absolute and cannot be used
	Ingroup: plugin
	Module: resolver
	At: /home/jenkins/workspace/libelektra_PR-2060-UC533EJXFEGIMCPXROAS5K3DQGSNDLWE3TI7WV4NENQDLGK2UB4A@3/src/plugins/resolver/filename.c:194
	Reason: XDG_CONFIG_HOME contains a path that is not absolute (violates XDG specification) and thus it was skipped: '/home/jenkins/workspace/libelektra_PR-2060-UC533EJXFEGIMCPXROAS5K3DQGSNDLWE3TI7WV4NENQDLGK2UB4A@3/xdg/user'

Modifying the path from
'/home/jenkins/workspace/libelektra_PR-2060-UC533EJXFEGIMCPXROAS5K3DQGSNDLWE3TI7WV4NENQDLGK2UB4A@3/xdg/user'
to
/home/jenkins/workspace/libelektra_PR-2060-UC533EJXFEGIMCPXROAS5K3DQGSNDLWE3TI7WV4NENQDLGK2UB4A@3/xdg/user
allows all tests to pass.

Expected Result

quotes should be stripped before testing for an absolute path

Actual Result

quotes are treated as part of the path and hence resolver.c treats it as relative path (which in turn violates XDG specs).

System Information

  • Elektra Version: master

Further Log Files and Output

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2060/5/pipeline/340/

@ingwinlu ingwinlu added the bug label Jun 10, 2018

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 10, 2018

Thank you for reporting the problem! Could you please point me to the place where the quoting is explained? Is it in https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html?

@ingwinlu

This comment has been minimized.

Contributor

ingwinlu commented Jun 10, 2018

Nowhere. But assume you want a path for xdg with spaces, then you would need quotes around it.

The current resolver.c implementation only checks the first char of the path to determine if it is an absolute path which might not be an / in case the path is quoted.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 10, 2018

Nowhere. But assume you want a path for xdg with spaces, then you would need quotes around it.

Why? Only colons would need to be escaped. But I cannot find any reference that paths with colons should be possible.

@ingwinlu

This comment has been minimized.

Contributor

ingwinlu commented Jun 10, 2018

Why? Only colons would need to be escaped. But I cannot find any reference that paths with colons should be possible.

Personal experience suggests always quoting paths. Since that is obviously not enough I did a quick search and found https://stackoverflow.com/questions/33318499/should-i-use-quotes-in-environment-path-names.

I have no idea what you mean with only colons would need to be escaped. While it is true (in case of spaces) you could circumvent the issue with escaping the white space it would still be worse to read then a quoted path.

Regardless of style guides and other opinions I would expect Elektra to work when i give it a valid path. even when it is quoted.

@markus2330

This comment has been minimized.

Contributor

markus2330 commented Jun 10, 2018

Of course you always need to quote paths to make the shell happy (to allow newlines and avoid the problems mentioned in the link). But the shell removes these quotes, so they never end up in the environment and are never seen by Elektra.

If you put quotes literally in the string, they are interpreted as file path. The only non-file path character in the *PATH variables is colon (:). But afaik there is no escaping so it is simply not possible to have colon in the file paths.

@ingwinlu

This comment has been minimized.

Contributor

ingwinlu commented Aug 28, 2018

Closed as a wontfix

@ingwinlu ingwinlu closed this Aug 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment