| View previous topic :: View next topic |
| Author |
Message |
emc
Guru
Joined: 02 Jul 2004
Posts: 564
Location: Cracow, Poland
|
 Posted: Mon Sep 22, 2014 10:10 am Post subject: uselessd |
 |
|
I know isn't ready yes, but maybe worth to intressed in to get another choice in gentoo:
http://uselessd.darknedgy.net/ |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Sep 22, 2014 10:50 am Post subject: |
|
|
I hope that it will go to the portage tree.
Unfortunately, systemd-208 is a bit too early to have support for all current tmpfiles.d flags, but maybe this is being backported. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Sep 22, 2014 11:19 am Post subject: |
|
|
cross-posting what I posted on this in OTW:
Two things worth noting about this side project (depending on how serious it is - note there is already a project to re-implement SysD for BSD as small as possible)
1) The more clones that exists, the more it provides validation (to sysd proponents) that not only was what was done was wrong BUT the sysd approach is correct (NOTE sysd position has always been comparing against sysvinit BUT with more modern init like OpenRC - if OpenRC can get socket activation it would be a real contender/remove an argument against bar OneTrueScotman)
2) Sysd has for quite some time asserted that foo has to be integrated into sysd as the only way (the logger, udev...) The fact these have been ripped out and something has been shown to function is interesting in shooting down that stance that the over-complication of Sysd is snakeoil & is embrace,extend driven (WTF does an init system need a httpd...). If they are willing to overplay things like this, can they be trusted for other things?
Sysd is big, svchost big... & their insistance it is modular and it uses shared libs is flawed. It maybe modular, it may used "shared libs" but they are all intertwined and cannot actually be used independently --> it is a monolithic design for something that should be simple, PID1 at least should be.
three interesting reads
http://ewontfix.com/14/ - why PID1 should be simple. Make sense. PID1 REALLY simple then a more complicated PID2
http://0pointer.net/blog/projects/systemd.html - why PID1 needs to be complex
http://felipec.wordpress.com/2013/11/04/init/ - another init system  we need MOAR!!!!
also interesting read; http://ewontfix.com/15/ BASICALLY SystemD only really does what it states for daemons written to interface to Sysd via Dbus/Sockets, ie full integration & even then there are cases that this will be hard.
| Quote: | | As it stands, my view is that systemd has failed to solve the problem everybody thinks it's solved: making dependency-based service startup work robustly without the traditional hacks (like sleep 1) all over the place in ugly init scripts. What it has instead done is setup a situation where major daemons are going to come under pressure to link to systemd's library and/or integrate themselves with D-Bus in order to make systemd's promises into a reality. And this of course leads to more entangled cross-dependency and more platform-specific behavior working its way into cross-platform software. |
snakeoil
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Sep 22, 2014 5:19 pm Post subject: |
|
|
| mv wrote: | | Unfortunately, systemd-208 is a bit too early to have support for all current tmpfiles.d flags, but maybe this is being backported. |
tmpfiles.d doesn't need to be more than a simple sh script in any case, so it's hardly difficult to add new flags. I don't even see an argument for doing it in C, personally, as it's only ever run once on startup, and unless you're an amateur, sh is bloody quick.
C is much harder for the admin to tweak, when they need to, which also applies to users submitting patches. You get more patches or ideas against shell, ime, because people aren't scared of it, and it's immediate. Generally, that gives you more to go on, in terms of improvements.
OFC you still need competent shell scripters at the coalface, but isn't that what distros are supposed to be about: collective knowledge from people who know WTF they're doing?
| Naib wrote: | | 1) The more clones that exists, the more it provides validation (to sysd proponents) that not only was what was done was wrong BUT the sysd approach is correct (NOTE sysd position has always been comparing against sysvinit BUT with more modern init like OpenRC - if OpenRC can get socket activation it would be a real contender/remove an argument against bar OneTrueScotman) |
You appear to be contradicting yourself; on the one hand we should be careful of providing validation for systemdbug as a methodology, and on the other we absolutely need to get socket activation to "remove an argument." The problem is that socket activation is no substitute for true dependency resolution, and if you have the latter, why bother with all the rest? Especially when it means you have to rewrite portable daemons to make them work with the "init-manager to replace all others".
As you point out, the latter makes no sense at all; if systemd were any good, daemons wouldn't even know about it.
Not that I have anything against xinetd.
| Quote: | | PID1 REALLY simple then a more complicated PID2 |
This is exactly what we've been saying for the last 3 years. The simplest pid 1 out there that still does everything we need (they don't address signals in that skeleton) is in fact sysvinit.
The trouble is that systemd-fanbois conflate sysvinit with sysv-rc when the two are completely separate, which is why we can replace the latter with openrc.
From where I'm sitting, I can' t help but laugh when confronted with such muddled thinking. Are we really going to cede the linux userland to people who can't even get the basic facts right? Pfft. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Sep 22, 2014 6:04 pm Post subject: |
|
|
| steveL wrote: | | tmpfiles.d doesn't need to be more than a simple sh script in any case, so it's hardly difficult to add new flags. |
Whether it might be implemented as a shell script is a different story: In systemd and thus presumably also in uselessd, it is in C. So it is hard to add new flags.
| Quote: | | I don't even see an argument for doing it in C, personally, as it's only ever run once on startup, and unless you're an amateur, sh is bloody quick. |
No, it is not run only on startup: One of its purposes is to clean directories regularly. In fact, one of the things which might be missing now is the possibility to run things only on startup.
OK, since .timed units were removed in uselessd perhaps also this "cleanup" functionality was removed from systemd and it is run now only on startup.
Concerning C:
First of all, this should be one of the first tasks, perhaps even before "find" is available, so already from this viewpoint an implementation in C is at least convenient.
Moreover, this is one of the few tasks where sh really is lame: Running recursively through directories, checking whether they match certain masks (there are "x" and "X", checking dates and filetypes [e.g. filestamps of sockets should be handled differently than for ordinary files], ... I checked the implementation in systemd, and this is one of the few parts of systemd where the implementation really seemed to be thought through): This cannot be done with "find" alone, but "find" has to call a rather complex shell process which handles every file. The slowness (and actually also complexity in sh: Sending configurable patterns to a shell-command called through "find" is really ugly; moreover, if you use "find -exec ... +" you cannot tell find in such a script reasonably to "prune" a remaining branch) was one of the main reasons to rewrite squash_dir in perl which has a much more configurable File::FInd which reduced runtime by a considerable factor (for various reasons). In C it is even quicker, of course. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Mon Sep 22, 2014 6:16 pm Post subject: |
|
|
| steveL wrote: | | Quote: | | PID1 REALLY simple then a more complicated PID2 |
This is exactly what we've been saying for the last 3 years. The simplest pid 1 out there that still does everything we need (they don't address signals in that skeleton) is in fact sysvinit. |
I'm wondering what runit is lacking there. I know its pid1 has less features than sysv (I've had to reimplement a few), but how indispensable are they really? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Sep 23, 2014 11:54 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | tmpfiles.d doesn't need to be more than a simple sh script in any case, so it's hardly difficult to add new flags. |
Whether it might be implemented as a shell script is a different story: In systemd and thus presumably also in uselessd, it is in C. So it is hard to add new flags. |
In systemd, perhaps. But I've implemented the same thing at least twice now, for different people (and helped qnikst with tmpfiles in openrc.) The first time was just as a PoC for someone who was making his life far too difficult with an awk script writing another awk script: I stole the process_stdin() function we use at work, cut out extraneous features that weren't needed in this context, and it was a tiny script, that did everything he'd asked for, and wherein it was obvious how to extend it.
| Quote: | | In fact, one of the things which might be missing now is the possibility to run things only on startup. |
That sounds so stupid, words fail me.
| Quote: | Concerning C:
First of all, this should be one of the first tasks, perhaps even before "find" is available, so already from this viewpoint an implementation in C is at least convenient.
Moreover, this is one of the few tasks where sh really is lame: Running recursively through directories, checking whether they match certain masks (there are "x" and "X", checking dates and filetypes [e.g. filestamps of sockets should be handled differently than for ordinary files], ... I checked the implementation in systemd, and this is one of the few parts of systemd where the implementation really seemed to be thought through): This cannot be done with "find" alone, but "find" has to call a rather complex shell process which handles every file. The slowness (and actually also complexity in sh: Sending configurable patterns to a shell-command called through "find" is really ugly; moreover, if you use "find -exec ... +" you cannot tell find in such a script reasonably to "prune" a remaining branch) was one of the main reasons to rewrite squash_dir in perl which has a much more configurable File::FInd which reduced runtime by a considerable factor (for various reasons). In C it is even quicker, of course. |
Jeezus, WTF are you trying to do in tmpfiles? Are you sure you don't want a tar/cpio archive?
Anyhow, check out linux/scripts/gen_initramfs_list.sh (which could certainly be cleaner shell.)
Don't get me wrong: I don't have any problem doing it in C. I just think it's one of those things which is actually better done in shell, if we consider the context and the whole domain in the round.
C is more appropriate for something like linux/usr/gen_init_cpio.c which is no doubt where they got the idea; the format is very similar. However that doesn't mean it's the same task: it's actually much easier to do tmpfiles in shell, ime. Much less code, and it's very obvious what it's doing. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Sep 23, 2014 11:57 am Post subject: |
|
|
| Ant P. wrote: | | I'm wondering what runit is lacking there. I know its pid1 has less features than sysv (I've had to reimplement a few), but how indispensable are they really? |
Why not just run runit under sysvinit? |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Tue Sep 23, 2014 6:58 pm Post subject: |
|
|
| steveL wrote: | | Quote: | | In fact, one of the things which might be missing now is the possibility to run things only on startup. |
That sounds so stupid, words fail me. |
| systemd ChangeLog wrote: | CHANGES WITH 209:
* tmpfiles gained a new "--boot" option. When this is not used,
only lines where the command character is not suffixed with
"!" are executed. When this option is specified, those
options are executed too. This partitions tmpfiles
directives into those that can be safely executed at any
time, and those which should be run only at boot (for
example, a line that creates /run/nologin).
|
So, unless some relevant part of systemd-208 was rewritten, the !-flag is not recognized by uselessd.
| Quote: | | Jeezus, WTF are you trying to do in tmpfiles? |
Removing files with too old dates recursively, but preserving paths specified with options X or x, ignoring dates for sockets unless certain other options are specified etc.
As long as you can write it as one "find"-expression it is nice, but you probably have a chance for this only with GNU find, and perhaps even this is not sufficient (I did not seriously think about all required cases): In the moment when you need for at least one test a shell command you either have to spawn the shell for every file or you have to use "+" in which case you cannot reasonably prune.
| Quote: | | Anyhow, check out linux/scripts/gen_initramfs_list.sh (which could certainly be cleaner shell.) |
The problems with thiings like these is that they rely about GNU-find features for file-quoting or \0 handling (and then also about non-POSIX feature of being able to read such data): Otherwise you either cannot treat filenames with whitespaces/newlines/... properly or you have to use -exec; hence, either starting a shell for every file or deal with '+' and not being able to prune.
In case it is unclear what I am speaking about: Have a look at the function NeedSquash() from https://github.com/vaeth/squash_dir/blob/master/init.d/squash_dir
This function uses the function CalcIgnore() and a lot of ugly shell code just to "compose" one find-command with an appriate value of "-exec" to calculate the total size of certain files in POSIX. It is really ugly and slow... |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2282
Location: Adendorf, Germany
|
| Posted: Wed Sep 24, 2014 8:55 am Post subject: |
|
|
| mv wrote: | | steveL wrote: | | Jeezus, WTF are you trying to do in tmpfiles? |
Removing files with too old dates recursively, but preserving paths specified with options X or x, ignoring dates for sockets unless certain other options are specified etc. |
I'd remove or disable *any* tool that does something like that ASAP. If any program lets orphaned files laying around in /tmp or /var/tmp then fix the program and not put some sort of "garbage collector", that eventually *will* do things wrong any other day, in charge.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Sep 24, 2014 10:44 am Post subject: |
|
|
| Yamakuzure wrote: | | I'd remove or disable *any* tool that does something like that ASAP. If any program lets orphaned files laying around in /tmp or /var/tmp then fix the program and not put some sort of "garbage collector", that eventually *will* do things wrong any other day, in charge. |
Just to mention a few examples why this is needed: Having 1d in /tmp, i.e. removing all files not used within 24 hours from /tmp is very reasonable as a rule, especially if /tmp is a tmpfs. However, perhaps sometimes you have an emacs open even longer; emacs gets very angry if its tmpdir is removed all of a sudden and becomes almost unusable after this happened, especially if you are like me who has an .emacs which instructs emacs to store its "temporary" saves in /tmp instead of the current directory. So it makes sense to exclude /tmp/emacs*, at least for me. Similarly, if users use "keychain" they get a bad surprise if sockets in /tmp/ssh.* or /tmp/gpg.* are removed (timestamps of sockets do not change when they are removed).
Also the fact that e.g. you want to clean most stuff in /var/tmp rather frequently does not necessarily mean that you want the same frequency for /var/tmp/portage etc.
Maybe you do not have such a use case, but there are certainly people who have.
And concerning considering leaving files in /tmp as a bug: There are a lot of programs which do not catch signals. You will have a lot of fun if you want to "fix" all of them. Moreover, there are signals where it is not clear whether there should be a cleanup and other signals (like -9) where it is even impossible to do a cleanup. Even in "harmless" situations like pressing "Ctrl-C" twice a lot of prgrams even with a signal hander do fail to cleanup - sometimes perhaps intentionally.
In my experience, "most" files which are in /tmp after 1d are there by mistake, and quite often I find such files. Quite often it is a reminiscent of some plugin; usually I hardly ever know where it came from. There are enough proprietary tools on my system which could be the culprit. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Sep 24, 2014 11:50 am Post subject: |
|
|
This discussion is starting to remind me of a program they used to run at work called "skulker" that basically deleted old stuff out of /tmp. Those were the old days on AIX, and I believe before "noatime" became common practice. Clearly skulker would misbehave on a noatime filesystem. I just took a look, and there is not skulker in portage, and the only mention in the forums was with regard to someone listening and not posting. A bit of time with Google and it appears that "skulker" is pre-Linux Unix. It's also more of a multiuser non-PC phenomenon where the admin fears someone using up /tmp and needs a policy enforcer to keep it clean and trim.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Sep 24, 2014 5:01 pm Post subject: |
|
|
It sounds like one use-case (cleaning up tmpfiles in /tmp) which is very much not the original purpose of tmpfiles.d (god i hate that name, it's so nub) is causing you hassle. I've always seen that as something an admin puts in a script called by cron, since it's bound to be site-specific.
I didn't get too far with your shell script, which I agree is very ugly. I've "composed" find sequences many times (written wrappers for it from bash, shell and make which really is tricky), so I'm not sure what difficulty you're having, apart from the obvious ones I see in the script, which no doubt you'd call "style" but I'd call "muddled".
I don't like all the eval at all, especially since you never check for validity (which is a simple minimal function call to case), and even more so because you insist on baroque excess bracing that simply makes the code much more opaque, by comparison to the shell routines we use (that do use eval, when forced.) Compare and contrast:
| Code: | eval mktempn=\${${1}}
eval mktempn=\$$1
|
and that's one of your simplest cases. No wonder you're getting muddled; Cleardir() is simply disgusting, as is NeedSquash().
Neither version is safe without checking the content of $1 first; you simply cannot rely on eval without checking the inputs, and your script is big enough that I wouldn't run it without such checks (well I wouldn't run it at all, in its present form.)
It'd be better if you just gave us the input format you're trying to work with, and what you want to happen. Though as stated, adding cleanup functionality to tmpfiles.d is simply another conceptual muddle from upstream, and admins are better off without it afaic.
In any case, your overuse of eval is totally borked afaic. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Sep 24, 2014 5:08 pm Post subject: |
|
|
| depontius wrote: | | This discussion is starting to remind me of a program they used to run at work called "skulker" |
SuSe (and I believe also Debian) previously had their own scripts in default cron jobs.
Since several years, the "classical" tool for this on most linux distributions is app-admin/tmpwatch
Of course, you can configure tmpwatch to watch for atime instead of mtime.
However, note that on many filesystems atiime is not necessarily a good idea, and /tmp is not necessarily on a separate filesystem.
Moreover, even if atime is available, it is not clear whether this is the correct criterion: I think in all my previuos examples, atime would not help, either (concerning sockets, I am not sure whether communication over them changes atime. If it does, this gigantic overhead might be yet another reason to disable atime...) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Sep 24, 2014 7:13 pm Post subject: |
|
|
| steveL wrote: | | No wonder you're getting muddled; Cleardir() is simply disgusting, as is NeedSquash(). |
I completely agree, but this is more or less the only way you can do it in POSIX. As I said: This type of task is simply nothing for which the shell is the appropriate language.
Once more, just to summarize why all this complex thing is needed: It is not possible in POSIX to "parse" the output of "find" reliably. If you want to do/check something for every file, you need to do this with "-exec sh". There is no possibility to pass to this shell code other shell functions except by writing them in the argument, and you cannot pass any argument to this "exec"-code besides reading exported environment variables. Moreover, the whole passed code should not be too long to avoid troubles with the kernel command line limit. So, if this function should contain customizable code, you have to "build" your function in advance from strings and configuration options. All this is just plain horrible. I had looked for quite a while for other solutions, but I found none.
It would not even have been worth a thought to code this in shell, if the whole project wouldn't have existed earlier without this function, whose need arise only later for some feature. As mentioned, when even more features should be added, it was clear that a rewrite in a saner language than shell was necessary.
| Quote: | | I don't like all the eval at all, especially since you never check for validity |
I doubt that you find any eval in the code that could be easily avoided in POSIX. And the script checks for validity where it makes sense: When dealing with user-input.
| Quote: | | Code: | eval mktempn=\${${1}}
eval mktempn=\$$1 |
|
A nice example where braces increase readability, simultaneously providing a very basic validity check which saves you from some accidental mistakes (like if you pass spaces) and also does the expected thing if ${1}=10.
You want to throw all three advantages over board without gaining anything. Fine, do it! But do not complain if others do not consider giving up advantages for nothing as such an ingenious great idea!
| Quote: | | Neither version is safe without checking the content of $1 first |
Even more: Neither version is safe without being absolutely sure that $1 is the intended variable name. If there is any chance that $1 is tainted, this code cannot be used: Doing any syntactic check of $1 would not help you, either, because a tainted value might do rather unforeseeable things, including tainting other variables.
(BTW: Since this is an init-script, bash is not an option for the code. But even if it were: using bash indirection to avoid the eval would actually be even more dangerous than to use the eval (the version with braces which saves you from most accidental mistakes): It would only hide the problem of tainted variables instead of making you alert like the eval above does.)
As usual, in shell code, you need the complete overview over all details of your script. This is one of the reasons why one is doing something fundamentally wrong if one writes complex code in shell.
| Quote: | | In any case, your overuse of eval is totally borked afaic. |
It is the shell language which is borked and which was never meant to be used for such complex things. I don't think any eval in this code could be avoided in the code without losing functionality. In bash, maybe some could have been replaced by variable indirection and some others could have been avoided, because you can pass "lists" of configuration values in arrays.
However, nothing would improve the code dramatically or make it better. Moreover, when you are using something like arrays, this is usually already a sign that very likely your code is already too complex and you better should have chosen a high-level language with even more types (and perhaps even a static typechecking). |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Sep 25, 2014 5:29 am Post subject: |
|
|
| mv wrote: | | It is the shell language which is borked and which was never meant to be used for such complex things. I don't think any eval in this code could be avoided in the code without losing functionality. |
Pfft. Like I said before, just give us the input format you're trying to work with, and what you want to happen, that is so immensely complex. Right now I can't see the wood for the crappy eval trees. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Sep 25, 2014 8:32 am Post subject: |
|
|
| steveL wrote: | | Pfft. Like I said before, just give us the input format you're trying to work with, and what you want to happen, that is so immensely complex. |
If you really want to spend your time coding complex things in shell, despite a simple solution in perl exists (and is certainly not going to be reimplemented in poor shell, even if suprprisingly you should find a simple solution to this partial task):
The task of need_squash is to honour all IGNORE* configuration variables described in https://github.com/vaeth/squash_dir/, determining whether non-matching files do exist in the tree.
Most of them can be translated into "find" options (using the non-POSIX -path); for 6 "arrays" of configuration data essentially only 3 eval's are needed - show me how to do it with less without writing a cumbersome shell parser in shell (as you can see in the code, some of these arrays are further extended by "fixed" data). The difficult part is the configuration variable IGNORETOUCH which cannot be done with "find" alone, because "diff" and filetype comparison have to be called for the configured files with the corresponding files from another filetree, doing this comparison only if necessary to save time. As a bonus (only partially implemented in the shell script, not in this function): calculate the total size of the non-ignored non-matching files and decide whether this size reaches a certain threshold (in the latter case, stop the rest of "find" immediately: The whole task is to find as quickly as possible whether this threshold is reached).
| Quote: | | Right now I can't see the wood for the crappy eval trees. |
Besides these 3 mentioned eval's, I see in the corresponding code only 2 to evaluate the two calls of "find", and another one to return a value from a function in a specifieid variable: Unfortunately, shell has no other clean way to do this; the hack "$(funtion)" which is sometimes used for this is not only horribly slow but also cuts e.g. trailing newlines, so as a rule, for functions which return values, the first argument is used as the name of the "return" variable (which is completely safe, of course; at least, as safe, as would be bash indirection).
In my opinion what makes the code hard to read is not only the unavoidable eval's and related necessary quoting but also the variable names: Unfortunately, POSIX shell does not know the "local" keyword which IMHO is the biggest drawback of POSIX. So a "namespace" has to be used by discipline; a good way is to prefix the function name to the "local" variable name. A better way is, of course, to use a higher language than shell to start with... |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Sep 26, 2014 5:02 pm Post subject: |
|
|
| mv wrote: | | Besides these 3 mentioned eval's, I see in the corresponding code only 2 to evaluate the two calls of "find", and another one to return a value from a function in a specifieid variable: Unfortunately, shell has no other clean way to do this; the hack "$(funtion)" which is sometimes used for this is not only horribly slow but also cuts e.g. trailing newlines, so as a rule, for functions which return values, the first argument is used as the name of the "return" variable (which is completely safe, of course; at least, as safe, as would be bash indirection). |
This would be those names I was indicating should be valid, but you wanted to sidetrack into passing in {10}.
| Quote: | | In my opinion what makes the code hard to read is not only the unavoidable eval's and related necessary quoting but also the variable names: Unfortunately, POSIX shell does not know the "local" keyword which IMHO is the biggest drawback of POSIX. So a "namespace" has to be used by discipline; a good way is to prefix the function name to the "local" variable name. A better way is, of course, to use a higher language than shell to start with... |
Yes, I wanted to point out before that a shell has to support 'local' in order to be acceptable to debian as a /bin/sh. POSIX has been discussing standardising it; the only contention is whether it shall be a true dynamic scope, or the equivalent of 'auto'. We'd prefer the former. In the meantime, we already use it, and live with the ambiguity (which is why variables you want to use across functions must be global.) mksh for instance, supports it as an alias for typeset, whenever it's run as sh.
Further I don't understand why you'd preclude GNU find on a Linux installation, but then I wasn't quite sure what you were doing; my bad, got confused with the tempfiles thing. Do what you want in your own project, ofc, but I'm not sure what point it makes in relation to the tempfiles issue we were discussing.
I saw a few things I'd change in that script, but clearly you're not interested (since "eval is the only way to indirect a variable, therefore I must write half a page of eval." Let's pontificate about how crap sh is instead.) |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Fri Sep 26, 2014 6:27 pm Post subject: |
|
|
| steveL wrote: | | I saw a few things I'd change in that script, but clearly you're not interested |
Indeed, this project is not maintained anymore. The reason is not the complexity of the code but that with squashmount it has a successor which is superior in many aspects: The rewrite took many lessons from the previous intensive usage of squash_dir.
For instance, it was a mistake to concept squash_dir as an init-script, to start with, since you cannot easily pass parameters to init-scripts but need to do this, since sometimes you want to call it manually with different options. This was handled over "magic files" and some wrapper which was a horrible hack from the very beginning. squashmount supports multiple mount-points properly from the beginning and can be used interactively much better.
| Quote: | | since "eval is the only way to indirect a variable, therefore I must write half a page of eval." |
eval must be used on the full command. The reason that this command is half a page is only that a huge list of arguments is added to the variables for the function call. Of course, this could be redundantly stored in another vairable to make the eval shorter. But why? There is nothing wrong with using eval if you do it carefully. |
|
| Back to top |
|
|
HungGarTiger
Apprentice
Joined: 04 Feb 2014
Posts: 180
Location: /nz/auckland
|
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Sep 27, 2014 5:43 pm Post subject: |
|
|
| steveL wrote: | | Why not just run runit under sysvinit? |
Personal preference. I found and fixed plenty of other bugs by doing it the hard way, though. They're gathering dust in b.g.o. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Sep 27, 2014 7:08 pm Post subject: |
|
|
@Ant: yeah I saw that other thread; looking at the process-tree, it makes sense if runit is supervising, and is designed to run as pid 1.
My personal preference is just to leave sysvinit as-is, and start the supervisor from there, though really I want that as part of openrc.
After all it's doing everything we could want from pid1, and the separation makes logical sense. |
|
| Back to top |
|
|
Shamus397
Apprentice
Joined: 03 Apr 2005
Posts: 218
Location: Ur-th
|
| Posted: Mon Sep 29, 2014 4:03 pm Post subject: |
|
|
@HungGarTiger: That Chris Fisher got his marching orders from somewhere seems obvious, especially in light of his 180° turnaround on Gnome 3.x (around the beginning of the year?--originally he panned it, then a few weeks later said he was going to use it exclusively as his new desktop).
Fisher apparently has no choice in the matter; he has to do what he's told which is to shout down all opposition to SystemD. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
