[Github-comments] [geany/geany] Domain socket error: Not working via sudo is a geany bug, not a feature or bug in sudo (#1150)

[doublemeat]

@elextr Thanks for the thoughtful response.

I did actually use Geany for Javascript and Bash script development. Mostly bash. (And system config file editing. Fstab, apt sources, interfaces, etc.) And also as an omnipresent notes app.

I have two really useful scripts that conditionally launch editors various ways. The two most useful tools I think I have. I know others who do similar things. One script opens up a specified file normally with nano, if the user is in a terminal and there is no GUI environment available. But if there is a GUI environment available (whether in a terminal or not), it launches (formerly Geany). The other one is even more handy, it's for opening a file via gk/sudo. If launched from a terminal window, it prompts for sudo if necessary. Then if there is a GUI, it used Geany via sudo to open the file. If no GUI, nano. This is a huge time-saver when editing multiple files sequentially with sudo, to avoid typing in password every time. If it is not invoked from a terminal (e.g. "run" dialog), then it gets sudo via gksudo.

I can't imagine setting up new systems or administering existing ones without this. (And I'm not a fan of leaving a terminal open via sudo bash, but even if I did the same problem would exist.)

So, maybe that helps illustrate a good use case, or maybe not.

But either way, I'm left with the question: Why do the half-dozen other "lightweight" editors not suffer from this problem? What/how are they doing different? When I run any of them with sudo and then regularly, at the same time, regardless of order, there is no conflict and no anomolies of mixed-up states. I'm not even sure what you need a "socket" for in the first place, or why you call it that. (Presumably this isn't a TCP socket?) I'm guessing it's just a temp file having something to do with maintaining state. I'm assuming that's my own lack of knowledge of some established architecture paradigm you are using, and although I am genuinely curious, I can't imagine anyone losing sleep over me not knowing.

If you really are just using it to maintain state, why not just do so in memory and let OS-level paging take care of "physical instantiation"? And why does Geany need to know where this socket is at startup? Why _can't_ it instantiate a tempfile at startup? So what if there are multiple temp files, possibly unused ones stacking up in the case of unclean Geany shutdowns? (That's a big reason why some /tmp directories map to RAM, and almost all are deleted at startup.)

Again, I'm not expecting an answer. We're all busy. I'm just curious.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/1150#issuecomment-243674421
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160830/ea37cf81/attachment.html>