-
Notifications
You must be signed in to change notification settings - Fork 72
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
Handle system detection like shell detection. #159
base: master
Are you sure you want to change the base?
Conversation
@lucc that's awesome re: the sed command in the Makefile, I didn't know you could do that. As for generating platform specific code, it's up to you, but I don't think it's worth the effort. The platform checks are cached and don't effect runtime speed very much, and there are other areas we could spend time on that would be of more benefit, like adding proper support python and ruby docs etc. Let me know when you want me to merge this. |
@lucc I think I may need this for vimcat, at least the system detection include. |
Sorry I don't understand you last comment. Can you elaborate? As far as I can see (with grep) the variables set in inc/system.sh are never used in vimcat. vimcat has a small bit of independent code to check the system it is running on. |
About 58d5648: I don't where vimcat uses the code from the system detection in vimpager (that I moved to About 049ff27 and putting variable definitions on one line: In which file do you want to have them on one line? In About 50915c6: This is actually a preparational commit for something that I had planned (and that was the original intention of this PR): I think we could handle commands like |
Yes, the point is that it does not use it but I want to use it there.
The echo should be one line, so that the included block of code is not huge.
This will not work. There are too many differences between configurations of OSes and too many OSes. E.g. a Solaris user may have gsed and gawk installed or not etc. Further e.g. openbsd/netbsd/freebsd are essentially the same for my purposes and so don't need separate platform files, and the same caveats apply there about user-installed utilities. And most importantly this is completely unnecessary, adds a layer of complexity for no gain in either performance or maintainability. |
Ok, I pushed some new commits (and squashed the old ones). Maybe I can explain my idea better with this. for 1: you could try to source for 2: the for 3: Maybe 29b81d7 can make it more clear what I think. The idea is started there and I am looking for more places where I can do this. Related to 29b81d7: I noticed (with the new f3eacbb is just another idea for more variables and code paths that could be incorporated in this approach. In the end |
Good catch there, that happens because they are used in subprocesses, so they have to be primed at init time. |
I added some more commits. The head and tail wrapper functions have the same problem as the sed and awk wrappers. The commits about $runtime, $PREFIX and $vimcat show more of my plan in this PR. |
@lucc can you update this one and I'll take a look |
Dropped some commits due to the recent config PR. |
@lucc This is good, but I was thinking, why not put the functions into platform.sh as well, that way the whole thing is encapsulated in that file. Also please rebase and squash into fewer commits. |
Do you mean And I don't feel like these functions really belong in We could of course add marker comments to # setting variables
AWK=...
: ...
# START OF FUNCTION DEFINITIONS
awk () {
.... and in the makefile we could do something like Or do you have a better idea? |
We could also rearrange the runtime into:
then the platform file can be included from the share dir. Also I can rewrite head_n and tail_n to use normal head/tail syntax. |
Which files would go into I like the last point and would like to keep it. It feels strange to me that installed software should investigate the system it is running on and try to bootstrap stuff like the shell and head/tail syntax it can use. In my opinion such bootstraping is ugly and should stay in |
Instead of using head_n/tail_n functions use head and tail functions that take -<N> as the first parameter, like the actual utilities. Also for the man page detection, detect NAME with overstrikes as well.
@luc ^^ I rewrote head and tail to use normal syntax. Anyway, head and tail are not that important, except in the case of tail not understanding Anyway, we can solve 99% of these problems by just checking that /usr/xpg6/bin:/usr/xpg4/bin is in the PATH and prepending it if necessary. Of course I don't know the configuration of every possible platform, so this more cautious approach may be better for edge cases. The reason the checks have to run at runtime is because the configuration of the system can change after the software is installed. E.g. on Solaris, someone may first install vimpager and then only later install OpenCSW and the GNU utilities. |
@lucc yeah maybe |
I like d501c9a !! I feel like I have to give up on understanding Solaris and it maybe conformity to POSIX. |
I will explain Solaris some, although I'm by no means an expert. First, I suggest you get a Solaris 10 virtual machine image to play with here. it's in VirtualBox format, VMWare and Parallels can import this, and there are converters. Or you can just use VirtualBox. Install the appropriate UTF-8 locale and OpenCSW. Use these instructions to install the locale. You'll need to download the iso and mount it as a virtual disc in your VM for this. Ok, now on to the good stuff. Solaris keeps original UNIX utilities in
The xpg6 utils are newer, but most are in the xpg4 directory. These are significantly better and generally POSIX compliant. For example, Also |
I managed to download and run the Solaris VM. So now I can see the oddities myself. I want to share with you some of my thoughts and explain why I am so annoyingly persistent about all these bootstrapping and executable finding stuff. I hope that the other systems do not undermine my idea by being equally strange in a different way. (Please tell me if there is one.)
|
57241d4
to
d566a1f
Compare
0219fce
to
193783a
Compare
193783a
to
f824317
Compare
This simplifies some search patterns that are used in the makefile to copy sourced scripts into the "compiled" versions. The simplified patterns should be more robust to minor comment or quoting changes.
I think we can even add more commits to this PR but I wanted to discuss it first.
My idea was to get rid of all these
if [ -n "$some_system" ] ...
checks in the installed script in the end. Therefore we would need a file for each system that needs special code to emulate the things likeseq
ortail -n
and so on. The git version would source the correct file and the makefile could then include the correct function into the "compiled" versions (configured and standalone scripts) at "compile" time.The idea comes from
pass
again. On line 189 they do this:and in the makefile they change the path of the platform file and install the correct platform file for the system into
/lib
: