Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[New package] emod, easily edit your use flags
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Thu Feb 21, 2013 8:21 am    Post subject: Reply with quote

John R. Graham wrote:
sera wrote:
BoneKracker wrote:
Also, while most of them are lucid, some USE flag descriptions could be a little more explicit than "enable support for foo". :lol:

Can't but agree here. Horrible. :lol:
My cut on this from several years ago.

- John


Truth needs be told! Seriously, a very good read. Continuing with gcc's gtk use flag on b.g.o
Back to top
View user's profile Send private message
sera
Retired Dev
Retired Dev


Joined: 29 Feb 2008
Posts: 1017
Location: CET

PostPosted: Thu Feb 21, 2013 8:50 am    Post subject: Reply with quote

steveL wrote:
... posix.sh .... embedded ... ramble ... posix.sh .. ramble ... reinvent wheel ... posix.sh ...


I really think it's an inappropriate language choice for such a tool. I suggest you start with the xml parser. If it were that straight forward old tools would have been fixed long ago. For a tool to do the right thing it needs to reimplement quite a portion of a package manager. So if you are gonna reuse code that leaves python, ruby and c++.

A python api is provided by all package managers so the one in paludis sucks I heard. Portage is in the process to create a proper public api which can be used by tools like this one. Flaggy as far as I'm aware is using gentoopm, a cross package manager api/glue. Flaggy should be current and working so I haven't played with it yet and can't tell you more about it.

Another popular one I now remember was ufed.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Feb 22, 2013 9:22 pm    Post subject: Reply with quote

sera wrote:
I really think it's an inappropriate language choice for such a tool. I suggest you start with the xml parser.

Oh man, are you for real? sh is inappropriate, let's stick some XML into the mix even though it has nothing to do with anything? That's the kind of idiotic thinking that brings us hal/udev and dbus needing XML for basic system tasks.

Quote:
If it were that straight forward old tools would have been fixed long ago. For a tool to do the right thing it needs to reimplement quite a portion of a package manager. So if you are gonna reuse code that leaves python, ruby and c++.

No offence, but you have no clue what you are talking about.

I remember ufed too: I replaced everything it did in update about 4 years ago, keeping use euse for globals as I don't have an issue with it. I replaced autounmask a few months later when it had some bugs, as I didn't really like the extra dep in any case, and could do a better job from BASH (and its interaction with portage now is still much more convenient.)

You appear to be under the illusion that porcelain should reimplement plumbing.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Sun Feb 24, 2013 4:10 pm    Post subject: Reply with quote

Hi, I have been quite busy the past few days and didn't find the time to answer though I read through all your answers.

Thanks for your interest. I see that opinions differ and it is quite hard for the novice I am to make one's mind on the raised issue.

Although using a posix shell in order to make the tool available on an initramfs is legitimate, I think that it is better to have a maintainable code useful in 95% cases than an unmaintainable one useful in 100% cases. Yet, another tool can be written to handle the 5% cases left, implementing less features, to keep it human understandable.

As far as I am concerned, though python have its drawbacks, I think it is a very good language for such kind of tools. It provides a very good readability with few comments and can make a (relatively) large set of things within a few instructions.

BoneKracker, you said that some portage tools need improvement/rewritting. I'm interested in the google summer of code, do you think it could be a good subject? (I will also ask the mailing list).
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Feb 25, 2013 9:18 pm    Post subject: Reply with quote

apinsard wrote:
Although using a posix shell in order to make the tool available on an initramfs is legitimate, I think that it is better to have a maintainable code useful in 95% cases than an unmaintainable one useful in 100% cases. Yet, another tool can be written to handle the 5% cases left, implementing less features, to keep it human understandable.

I have no issue whatsoever with your using Python, since you're clearly most comfortable with that, and as you say it can do a lot. But I cannot accept faulty logic like this. If anything, the 95% of simple cases should be implemented with simple tools. And sh is only as unreadable as you make it.

I'm happy to accept that it would be nice if there were simple utils we could call to do everything, and I applaud your efforts to do just that.

Until there are, small sh scripts that to do one simple configuration job well are perfect to hash out the command-line interface, and the implementation, especially combined with awk, or indeed just using awk itself. "The Awk Programming Language" (Aho, Kernighan and Weinberger, 1988) has many examples of this, and much more complex stuff, and the wider pattern is shown in the context of automated processes for programming, documentation and graphs, in "The Unix Programming Environment" (Kernighan & Pike, 1984). The latter is the book any aspiring coder should read imo, if they want to understand both the Unix philosophy and how to implement just about anything they can dream of using Unix utilities.

Further, I for one would prefer those simple base utilities to be written along the lines of portage-utils, which is very quick despite some awful algorithms (last time I looked.) But python is fine too: after all, you can't emerge anything without it. :-)
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Wed Feb 27, 2013 10:00 am    Post subject: Reply with quote

steveL wrote:
But I cannot accept faulty logic like this. If anything, the 95% of simple cases should be implemented with simple tools.


I don't understand what you mean my logic is faulty. (I think I didn't catch the last sentence.)

steveL wrote:
Until there are, small sh scripts that to do one simple configuration job well are perfect to hash out the command-line interface


That's true. I think that shell scripts are perfect to automate some daily series of commands. However, once it begins to handle many tasks and you have to make a lot of control flows, it becomes a lot harder to make it clean, readable and maintainable. Be it just to parse the arguments. Once again, this is a personal point of view, but I think I'm far from being the only one to think this way.

steveL wrote:
"The Awk Programming Language" (Aho, Kernighan and Weinberger, 1988) has many examples of this, and much more complex stuff, and the wider pattern is shown in the context of automated processes for programming, documentation and graphs, in "The Unix Programming Environment" (Kernighan & Pike, 1984). The latter is the book any aspiring coder should read imo, if they want to understand both the Unix philosophy and how to implement just about anything they can dream of using Unix utilities.


There are many interesting books to read. I put those to my list, thanks.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Feb 27, 2013 6:48 pm    Post subject: Reply with quote

apinsard wrote:
steveL wrote:
But I cannot accept faulty logic like this. If anything, the 95% of simple cases should be implemented with simple tools.


I don't understand what you mean my logic is faulty. (I think I didn't catch the last sentence.)

This was the context:
apinsard wrote:
it is better to have a maintainable code useful in 95% cases than an unmaintainable one useful in 100% cases. Yet, another tool can be written to handle the 5% cases left, implementing less features, to keep it human understandable.

The 95% of simple cases should implemented simply, which is more maintainable and robust: save the complex library loading for jobs that need it. According to your argument, the 95% of simple cases should be implemented with a more complex implementation, which makes no sense whatsoever.

Your argument for that position is that you think it's "more readable and maintainable" but this appears to be based on ignorance of sh and its metaphors. As an example, I already showed above how your use of lambdas to process a file is a lot less readable than the standard sh idiom.
Quote:
steveL wrote:
Until there are, small sh scripts that to do one simple configuration job well are perfect to hash out the command-line interface


That's true. I think that shell scripts are perfect to automate some daily series of commands.

Good and we agree that small scripts are also perfect to hash out the interface: they can be replaced simply, either with a small C program, or an awk script, or a script in a more complex language, all without the user even knowing the implementation has changed. And often there's no need to change the implementation, and in fact you can do much more complex things by using sh to wrap awk, which runs very quickly under busybox, for example.

Quote:
However, once it begins to handle many tasks and you have to make a lot of control flows, it becomes a lot harder to make it clean, readable and maintainable. Be it just to parse the arguments. Once again, this is a personal point of view, but I think I'm far from being the only one to think this way.

Again, it's just based on ignorance. So yes, lots of others think that way or look down on sh, but they typically have nfc how to use it either. As I said before, sh is as unmaintainable as you make it. You need to know the idioms of any language and have used them for a while before you can make an informed critique. And no offence, but you don't even have basic sh proficiency, from what you've said. Why not explore it before you denigrate it?

At least with sh, the most efficient way to read a file line-by-line (perhaps the most basic task in Unix processing) doesn't change from release to release. And it is efficient: it's the javascript of Unix, enabling admins to have full control of their machines, and to interact with it sanely (eg use of globs.) It's been doing that task since the days of 8-bit processors with a 64KB address-space, and Unix has been optimised for sane multi-processing since the beginning.

Yet suddenly it's all a calamity to use that basic infrastructure the way it was intended, because some crappy higher-layer doesn't know what modularity, coupling and cohesion are about, and sees the essential disciplines of the craft as needless restrictions to be sneeringly labelled "traditional", instead of what the grown-ups call them: "basic".
Quote:
There are many interesting books to read. I put those to my list, thanks.

Cool: when you've read UPE let me know, as I think you'll have a very different perspective, especially if you work through the exercises; most of all chapter 8.
Back to top
View user's profile Send private message
apinsard
n00b
n00b


Joined: 24 Mar 2012
Posts: 74
Location: France

PostPosted: Tue Mar 05, 2013 12:59 am    Post subject: Reply with quote

After thinking for a while, I decided to follow your advice and try coding it in bash. At worst, I would have learn a bit more about bash programming.

I started with a piece of code that check the validity of a package and enables to omit the category in most case : https://github.com/Pyntony/sysadmin/blob/master/erule/erule

I'd enjoy working with someone that already has a few backgrounds in tools development and could help me in the development process.

Thanks.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Mar 05, 2013 3:31 pm    Post subject: Reply with quote

Cool, let's get started :-)
Code:
function error() {
    echo $@ >&2
}

Using $@ is the correct way to pass on parameters, but it must be quoted. Without quotes, $* and $@ both mean the same thing: split the parameter list on spaces, irrespective of what they are. When quoted, "$*" is a single string, with each parameter joined by the first character of IFS, and "$@" is the list of parameters, split as you received it (ie correctly.) You almost always want "$@" when scripting.

However, for this function "$*" is more appropriate, since you just want to display the string. I'd go a bit further, and add die():
Code:
error(){
    echo "!! $*" >&2
}
die(){
    error "$*"
    exit 1
}

Note that there's no need to use function foo(), and in fact it usually doesn't work in other shells, so just stick with: foo() { blah..; }
Code:
read category package <<< `echo $atom | tr / " "`

Firstly, get used to using $(..) instead of `..`; $(..) was standardised by POSIX in 2001, and is much cleaner to work with. For a start it doesn't disappear in the text, and secondly it nests a lot better, should that be needed. In this case it isn't, and there's no need to subshell out:
Code:
local IFS=/
set -- $1
IFS=$oIFS
case $# in
    0) usage
;;  1) package=$1
;;  2) category=$1 package=$2
esac

..is how I'd do it in sh, where you setup: readonly oIFS=$IFS # at the start of your script, and usage is a function that prints a short usage message and exits:
Code:
usage(){
   echo "${0##*/} package" >&2
   exit 1
}

Alternatively, you can use SH parameter expansions. Let's get rid of any operator as well, as part of the function:
Code:
local atom=$1
while :; do
    case $atom in
    [![:alnum:]]*) atom=${atom#?}; continue
;;  */*/*) die "bad atom: $1"
;;  */*) category={$atom%%/*} package=${atom##*/}
;;  '') [ -n "$1" ] && die "bad atom: $1" || usage
;;  *) category= package=$atom
    esac
    break
done   
[ "$atom" = "$1" ] && operator= || operator=${$1%%"$atom"}

This is pure SH, and will work in busybox or mksh as well. Note that you must quote everything: the only exceptions are:
case $foo in ..: SH (and bash etc) is specified not to field-split the expansion of the word after a case.
foo=$bar: similarly for assignment, or things like: foo=$(sed -n '/^[[:space:]]*some crap:/{s///;p;q}' file) # would be a lot trickier. Note that you must still quote if you want spaces, eg foo='hi dee ho' or foo="bar is: $bar", and I've also noticed that foo="$*" is required if you are using an alternative IFS. foo=$* always uses spaces to join the args, at least in BASH.
Additionally, BASH does not require quotes inside [[, eg with [[ $foo ]]. However, you should be aware that the RHS of: [[ $foo = "$bar" ]] usually should be quoted, since it is treated the same as a case alternative, ie it gets used as a glob and if you don't want that, you need to quote it. An example is:
Code:
is_in(){
   [[ $1 ]] || return
   local v=$1; shift
   [[ " $* " = *" $v "* ]]
}

..as a quick test to see if something is in a small space-separated list. So this is slightly dirty, not for filenames or user input, but is okay if you know the content eg a configuration list of package names (ignoring that you have to split the incoming package version for now;)

That's all kinda advanced; standard advice to beginners is:
friendlyToaster wrote:
USE MORE QUOTES! Read http://wiki.bash-hackers.org/doku.php?id=syntax:words to understand why. http://www.grymoire.com/Unix/Quote.html will tell you how. -- Optimally, you should quote every parameter expansion ($foo).

It really is worth learning the SH parameter expansions, as well as the additional ones that BASH enables (see man bash, then hit '/' for a search, and type in 'Parameter Expansion'.) I wrote the Arrays part of that last link, fwtw; don't blame me for the Filename Expansions examples part though.

I've just woken up, so I'll leave it there for now. #bash are your friends ;-)
HTH,
steveL.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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