Talk:Xinit

From ArchWiki
(Redirected from Talk:.xinitrc)
Latest comment: Yesterday at 21:18 by Lahwaacz in topic How to write around startx conveniences

examples

there are 2 xinit examples which by themselves do not work as laid out, imo they should be removed and instead an optional note could be put (somewhere) that says something like:

xinit can be executed instead of startx if you know what options to use

otherwise it seems frustrating to recommend examples which will obviously fail --Ubone (talk) 02:29, 12 November 2018 (UTC)Reply[reply]

xinit would not obviously fail if you specified the options in xserverrc. If you already have an X server started, you should also pass the :display_number option mentioned in the note after the first example. -- Lahwaacz (talk) 07:35, 12 November 2018 (UTC)Reply[reply]
then replace or in #Usage with or if #xserverrc is configured: ? --Ubone (talk) 08:10, 12 November 2018 (UTC)Reply[reply]
I think it should be worded in a way to make it clear why xserverrc is relevant, after all the right options can be specified on the command line as well. -- Lahwaacz (talk) 22:04, 12 November 2018 (UTC)Reply[reply]

xinitrc.d scripts tip

Hmm as @Alad pointed out by the consideration of removal, I haven't thought about the .xinitrc actually being user content. I kind of thought about the way scripts are sourced as somewhat standard, even though there should really not be such expectation (even if it were kind of nice).

However I think it may be useful to somehow explain that the 'default implementation (on Arch?)' does source only executable files. Or I'm not sure. It just confused me that the x permission would be required, since the source command in bash does not require the file to be executable. Maybe there's a bigger reason behind this behaviour in the default .xinitrc - or maybe it shouldn't be like this, I'm not sure how other programs implement .d/ folders.

Feel free to delete this or improve on this, it was just a quick idea how to maybe save someone a while - but maybe it's too big of a headache and not that important.

I don't know how to rewrite what I added, again, feel free to moderate this.

Jsmetana (talk) 21:39, 7 December 2021 (UTC)Reply[reply]

I am confused as to why it's giving you trouble with non-executable files. It should be using the . builtin, which does not require the file to be executable. As for the shebang, that is useful information but I'm not sure if it belongs here - there are surely other places in the wiki that have the user write scripts, without mentioning it. :) - CodingKoopa (talk) 02:13, 9 December 2021 (UTC)Reply[reply]

Should the article explicitly mention more security considerations?

Quoting an answer to Xephyr -ac dangerously?

This also applies to any X server, not just Xephyr

Which is why I find it relevant for this talk page.

I haven't looked at how different display managers are starting X. Since a display manager is not mandatory, and some users can manage a multi user machine, I wonder if the xinit article should not have more pointers to security considerations. Regid (talk) 07:28, 6 April 2022 (UTC)Reply[reply]

How to write around startx conveniences

In view of the reversion https://wiki.archlinux.org/index.php?title=Xinit&oldid=806008, I'm asking how that edit should've been worded. As it stands, the paragraph is confusing, having lead me to believe that startx sessions also need an ~/.xserverrc to properly configure the VT argument. (This uncertainty is also why I chose to use the out-of-date template, rather than rip out the paragraph altogether - it was intended, though perhaps not legible, as an RFC)

Perhaps adding a paragraph clarifying that this configuration is only necessary for xinit would be enough?

Gesh (talk) 20:14, 15 April 2024 (UTC)Reply[reply]

We should not discuss how to properly word the template, but how to improve the section. If you change it to describe what actually happens in the background, it would be better. Some of your references might be still useful. — Lahwaacz (talk) 21:18, 17 April 2024 (UTC)Reply[reply]