Re: [dev] wswsh: a mksh web framework
On 2013-12-13 14:31:51 +0800, Patrick wrote: > Maybe give him the benefit of the doubt that he meant something like > 'maintains hierarchical taxonomy'. /2013/12/01/foo.html or /2013/12/01/foo/ -- I certainly don't care, but specifically trying to get the latter over the former is just insanity. pgpY30zyen9Bk.pgp Description: PGP signature
Re: [dev] wswsh: a mksh web framework
On 2013-12-13 14:25, Chris Down wrote: > > Is there an easier way to encourage clean URLs? > If masking files with directories is considered "clean", then I don't > want to live on this planet any more. Maybe give him the benefit of the doubt that he meant something like 'maintains hierarchical taxonomy'. Kai probably didn't mean 'taxa with file suffices are bad', just as he probably didn't mean 'racially pure' or 'std free'. ;)
Re: [dev] wswsh: a mksh web framework
On 2013-12-13 14:23:25 +0800, Kai Hendry wrote: > On 13 December 2013 14:20, Chris Down wrote: > > Did you really just say that every file should just be abstracted as a > > directory... how much of that web 2.0 Kool-Aid did you drink? > > Is there an easier way to encourage clean URLs? If masking files with directories is considered "clean", then I don't want to live on this planet any more. > Without resorting to crazy rewrites? Just don't do it. pgpyURARrQ87Q.pgp Description: PGP signature
Re: [dev] wswsh: a mksh web framework
On 13 December 2013 14:20, Chris Down wrote: > Did you really just say that every file should just be abstracted as a > directory... how much of that web 2.0 Kool-Aid did you drink? Is there an easier way to encourage clean URLs? Without resorting to crazy rewrites?
Re: [dev] wswsh: a mksh web framework
On 2013-12-13 14:09:25 +0800, Kai Hendry wrote: > you want foo.html to be exposed by your httpd as /foo/ ? No. > Only generate one index.html per directory. Simples. Did you really just say that every file should just be abstracted as a directory... how much of that web 2.0 Kool-Aid did you drink? pgpIZUJKlLmpi.pgp Description: PGP signature
Re: [dev] wswsh: a mksh web framework
On 13 December 2013 14:01, Chris Down wrote: >> You generate .html URLs. bit 90s and fugly. urls should be clean >> /2013/blogpost/ > Huh? That's the job of the web server. how? you want foo.html to be exposed by your httpd as /foo/ ? Only generate one index.html per directory. Simples.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 11:00 PM, Kai Hendry wrote: > RSS is dead. why bother? Why bother? The troves of people who cried at Google Reader shutting down would say otherwise. RSS is "dying" because companies like Google, Facebook, Twitter want to *own* the flow of information, and they can't do that when the world uses open plumbing. This is BS. I certainly want an open Internet, one where a filter bubble doesn't exist. Right now, the plumbing we have for this is RSS and Atom. To a lesser degree, I guess XMPP (see the efforts of the early autonomo.us (http://wiki.autonomo.us/Main_Page) movement) -- http://apgwoz.com
Re: [dev] wswsh: a mksh web framework
Oh Kai :-) On 2013-12-13 12:00:46 +0800, Kai Hendry wrote: > This sucks > > Why mksh? Can't you use POSIX shell? Enjoy your lack of useful functionality for no reason. At least mksh is reasonable (disclaimer: I have not looked at the code). > config files suck https://twitter.com/rob_pike/status/360557625756229632 "Just work" is myopic, in many situations it assumes that all users have the same end goals. Sane default configuration == good. Not being able to configure things == stupid (and yes, I consider config.h to be a "configuration file"). > RSS is dead. why bother? What on earth have you been smoking to say that RSS is dead? :-) > You generate .html URLs. bit 90s and fugly. urls should be clean > /2013/blogpost/ Huh? That's the job of the web server. > Feel free to mock my web framework: https://github.com/kaihendry/wordsister I'll refrain from saying something about PHP... :-) By the way, in that readme, you don't need to escape each expansion. Just quote the heredoc delimiter (ie. "<< 'EOF'"). pgpjSqRVD64a4.pgp Description: PGP signature
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 8:00 PM, Kai Hendry wrote: > You generate .html URLs. bit 90s and fugly. urls should be clean > /2013/blogpost/ Not the job of the static website generator.
Re: [dev] wswsh: a mksh web framework
This sucks Why mksh? Can't you use POSIX shell? .wshtml is used in your README. Actually only TXT works by default. smu is on my path, why interp? config files suck https://twitter.com/rob_pike/status/360557625756229632 setting up prefix in the Makefile sucks RSS is dead. why bother? You generate .html URLs. bit 90s and fugly. urls should be clean /2013/blogpost/ Feel free to mock my web framework: https://github.com/kaihendry/wordsister besos,
Re: [dev] wswsh: a mksh web framework
Quoth Thorsten Glaser: > I absolutely d̲e̲t̲e̲s̲t̲ Markdown. Really? Why? I quite like it (at least smu's subset). Works for the simple usecases I need it, and keeps the angle brackets of doom away from me.
Re: [dev] New utility "when"
>> On Dec 12, 2013, at 4:10 PM, "Fernando C.V." wrote: >> On Thu, Dec 12, 2013 at 10:49 PM, Fernando C.V. wrote: >> This way could do something like: >> >> $ when -t ssh host >>> xmessage DONE! > > Well... even if you didn't prompt it to the user interactively, it > would still be nice for aliases. > Probably most of the time you just want to get notfications: > > $ alias retry='echo "xmessage DONE" | when' > $ retry ssh host And if you only need simple messages, then there's nothing wrong with having to quote the "on success" command: $ when -t -c "xmessage Success" The advantage of specifying the message command as an argument (as opposed to &&) is that it allows you to pass through the return value of the main command. For example, if your long-running program is still running after the timeout, you get the message; but it may fail later, and you want to know about that too. $ when -t -c 'logger "Service started successfully"' non-forking-service || logger "Service exited unexpectedly" - Samuel Holland
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 02:32:03PM -0500, Andrew Gwozdziewycz wrote:
> find(1) seems very un-unixy, but it's very powerful.
It's not, though, because ultimately it's just a file system walk with a
system for querying stat(2). No, the problem I have with find is that
its output is not necessarily safe for easy usage in common shell
situations. That's what I have zsh's globbing for. (Seriously, recursive
globbing is the only reason I don't use mksh yet)
> Let's assume for
> a minute that find didn't exist. How would you do the following:
>
> 1. execute a command for each file (find . -exec whatever {} \;)
whatever **/*
> 2. find files that are > 8M
print -l **/*(LM+8)
> 3. find files that are older than 20 days
print -l **/*(m+20)
> 4. find all files that are owned by 'joe' that also have execute
> permissions for world
>
print -l **/*(u.joe.X)
[...]
> Thoughts? Pointers to tools that already do this?
>
All of the above have the same problem: If I do
for i in $(find . -foo); do
...
done
then this will fail if any file contains something in IFS. If I do
find . -foo | while read line; do
...
done
then this will fail for files with a newline in the name. Granted, that
doesn't happen often, but I don't want to think about such trivialities
in shell scripts that might work with untrusted data. If I do
for i in **/*(flags); do
...
done
then zsh will expand the glob correctly, no matter what those file names
contain. And in none of the above is the situation improved by replacing
find by another, more limited tool, because the problem is the interface
between tools and the shell.
> Cheers,
>
> Andrew
> --
I think that should be dash-dash-space.
Ciao,
Markus
Re: [dev] wswsh: a mksh web framework
YpN dixit: >I wrote a shell script using mksh, which generates websites. You need to write Just for completeness: I’ve written MirWebseite as a non-generic thing to generate static XHTML websites, too, and even got a second only slightly related installation (which, ofc, by now deviates quite a bit from the installation on the MirBSD/mksh website). Though, it needs the “CMS” user to provide valid XHTML/1.1 fragments; I absolutely d̲e̲t̲e̲s̲t̲ Markdown. And Natureshadow has written “SARAH” which is something similar, too. Turns out shell is not half bad at this kind of stuff ;-) So we have three exemplary “things” (I refuse to call my stuff a “framework”) in at least four installations, which people interested can have peeks at. bye, //mirabilos, wondering why t f anyone would want to do this in C which is obviously not TRT for string ops -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 5:30 PM, Andrew Gwozdziewycz wrote: > On Thu, Dec 12, 2013 at 5:26 PM, Bobby Powers wrote: >> Hello, >> >> Andrew Gwozdziewycz wrote: $ time find / | grep 'bin' > /dev/null real0m8.122s user0m3.101s sys 0m2.519s $ time find / -regex 'bin' | grep real0m18.795s user0m3.394s sys 0m3.401s >> >> I get a different story on Linux 3.12.4: >> >> [bpowers@fina ~]$ time find / 2>/dev/null | grep 'bin' > /dev/null >> real 0m2.316s >> user 0m1.145s >> sys 0m1.480s >> >> [bpowers@fina ~]$ time find / -regex 'bin' 2>/dev/null >> real 0m2.132s >> user 0m0.753s >> sys 0m1.362s >> >> [bpowers@fina ~]$ find --version | head -1 >> find (GNU findutils) 4.5.11 >> >> The find -regex is consistently about 10% faster. Not much, but also >> not > 2x slower like you see on OSX. >> > > Let me retry killing the output as fast as possible as you did. I still get something quiet equivalent, though this time it was 14s to 10s, so it doesn't appear to be console slowness. find is apparently just bad on OSX. BTW, there's no version or help flag for this find. That should say something about it.
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 5:26 PM, Bobby Powers wrote: > Hello, > > Andrew Gwozdziewycz wrote: >>> $ time find / | grep 'bin' > /dev/null >>> real0m8.122s >>> user0m3.101s >>> sys 0m2.519s >>> >>> $ time find / -regex 'bin' | grep >>> real0m18.795s >>> user0m3.394s >>> sys 0m3.401s > > I get a different story on Linux 3.12.4: > > [bpowers@fina ~]$ time find / 2>/dev/null | grep 'bin' > /dev/null > real 0m2.316s > user 0m1.145s > sys 0m1.480s > > [bpowers@fina ~]$ time find / -regex 'bin' 2>/dev/null > real 0m2.132s > user 0m0.753s > sys 0m1.362s > > [bpowers@fina ~]$ find --version | head -1 > find (GNU findutils) 4.5.11 > > The find -regex is consistently about 10% faster. Not much, but also > not > 2x slower like you see on OSX. > Let me retry killing the output as fast as possible as you did. -- http://apgwoz.com
Re: [dev] alternatives to find for querying the filesystem
Hello, Andrew Gwozdziewycz wrote: >> $ time find / | grep 'bin' > /dev/null >> real0m8.122s >> user0m3.101s >> sys 0m2.519s >> >> $ time find / -regex 'bin' | grep >> real0m18.795s >> user0m3.394s >> sys 0m3.401s I get a different story on Linux 3.12.4: [bpowers@fina ~]$ time find / 2>/dev/null | grep 'bin' > /dev/null real 0m2.316s user 0m1.145s sys 0m1.480s [bpowers@fina ~]$ time find / -regex 'bin' 2>/dev/null real 0m2.132s user 0m0.753s sys 0m1.362s [bpowers@fina ~]$ find --version | head -1 find (GNU findutils) 4.5.11 The find -regex is consistently about 10% faster. Not much, but also not > 2x slower like you see on OSX. yours, Bobby
Re: [dev] alternatives to find for querying the filesystem
Huge copy paste fail! > Also, just for kicks I ran a comparison: > > $ time find / | grep 'bin' > /dev/null > real0m8.122s > user0m3.101s > sys 0m2.519s > > $ time find / -regex 'bin' | grep > real0m18.795s > user0m3.394s > sys 0m3.401s That should have been $ time find / -regexp 'bin' > /dev/null for the second example -- http://apgwoz.com
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 3:36 PM, Troels Henriksen wrote: > Troels Henriksen writes: > >> Andrew Gwozdziewycz writes: >> >>> Assume that each filter halves the fileset of, say, 256 files (my /etc >>> directory on this OSX machine has just 247 files). That's less than >>> 512 calls with a few filters. Is that really so bad on modern >>> hardware? >> >> If you have only 256 files, you can do almost anything and it'll still >> be fast. Think tens of thousands, at the very least. >> >> I like the general idea of this, but I'd advise you not to go overboard >> with the tool splitting. You can easily have a single "filegrep" tool >> that includes all queries about size, age and the like, paired with >> another tree-walking fool. > > Actually, on second thought, there's no way to make this fast. You > *must* be able to perform filtering during tree traversal, or you may > end up traversing huge subdirectories unnecessarily. Is it possible for find to eliminate huge subdirectories? It seems to have the exact same problem. If your "query" is at the file level, ain't nothing you can do. You could modify walk with a way to exclude directories of course. walk -e var/run/ -e bin/ Again, part of this is that you potentially know the file system better than find does, so you can construct a pipeline that eliminates files more quickly. Of course, that means you're going to end up typing a lot every time: walk /var | ownerp -u ~root | sizep +1M And, now that I think about it, walk never has to stat the files, which means you can do a fair amount of filtering before making any system calls that aren't directory related. Also, just for kicks I ran a comparison: $ time find / | grep 'bin' > /dev/null real0m8.122s user0m3.101s sys 0m2.519s $ time find / -regex 'bin' | grep real0m18.795s user0m3.394s sys 0m3.401s This is on a very recent Macbook Pro, so SSD and all that jazz. I did this a few times. Numbers are similar through every run. It's possible that this is being caused by find's regex engine (which might suck horribly). So, I'm perhaps *not* convinced that this would always be slower. -- http://apgwoz.com
Re: [dev] New utility "when"
On Thu, Dec 12, 2013 at 10:49 PM, Fernando C.V. wrote: > This way could do something like: > > $ when -t ssh host >> xmessage DONE! Well... even if you didn't prompt it to the user interactively, it would still be nice for aliases. Probably most of the time you just want to get notfications: $ alias retry='echo "xmessage DONE" | when' $ retry ssh host -- Fernando
Re: [dev] New utility "when"
An alternative would be to read one of the commands from stdin. This way could do something like: $ when -t ssh host > xmessage DONE! You won't get tab-completion and other interactive fancyness, but it won't be missed for simple notification commands. -- Fernando
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 7:32 PM, Andrew Gwozdziewycz wrote: > Thoughts? Pointers to tools that already do this? When I need to do something like that, I use rc(1) and the plan9 version of ls(1). It shell-quotes the filenames by default which is very useful! -- __ Raphaël Proust
Re: [dev] alternatives to find for querying the filesystem
On Thu 12 Dec 2013 at 11:32:03 PST Andrew Gwozdziewycz wrote:
walk - (implements find $1)
AT&T Research has a tool called tw ("treewalk") that does this:
http://www2.research.att.com/sw/download/man/man1/tw.html
Assuming the sourcecode I downloaded a while ago is still current, it's
licensed under the Eclipse Public License, Version 1.0.
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 7:36 PM, Chris Down wrote: > On 2013-12-12 14:32:03 -0500, Andrew Gwozdziewycz wrote: >> So, to find all files in /etc modified within the last hour... >> >> walk /etc | agep -1H - >> >> Or, >> >> walk /etc | xargs agep -1H > > The problem here is speed. For any non-trivial number of files, this > will become non-negligibly slower due to the number of stat family calls > required (and the cost of reinterpreting the data each time). What about having said tools *and* a mini interpreter (for when speed matters). wafi: walk and friends interpreter % wafi "walk foo/bar/ | agep -1H - | permp +ox -" would be a fast equivalent to % walk foo/bar/ | agep -1H - | permp +ox - You could even chain with non interpreter-supported filters: % wafi "…" | whatever | wafi "…" The advantage of this wafi (really needs a better name if it is ever implemented) is that the syntax for the supported mini-language is a dumbed down shell! The main inconvenient is the quoting nightmare… -- __ Raphaël Proust
Re: [dev] alternatives to find for querying the filesystem
Troels Henriksen writes: > Andrew Gwozdziewycz writes: > >> Assume that each filter halves the fileset of, say, 256 files (my /etc >> directory on this OSX machine has just 247 files). That's less than >> 512 calls with a few filters. Is that really so bad on modern >> hardware? > > If you have only 256 files, you can do almost anything and it'll still > be fast. Think tens of thousands, at the very least. > > I like the general idea of this, but I'd advise you not to go overboard > with the tool splitting. You can easily have a single "filegrep" tool > that includes all queries about size, age and the like, paired with > another tree-walking fool. Actually, on second thought, there's no way to make this fast. You *must* be able to perform filtering during tree traversal, or you may end up traversing huge subdirectories unnecessarily. -- \ Troels /\ Henriksen
Re: [dev] alternatives to find for querying the filesystem
Andrew Gwozdziewycz writes: > Assume that each filter halves the fileset of, say, 256 files (my /etc > directory on this OSX machine has just 247 files). That's less than > 512 calls with a few filters. Is that really so bad on modern > hardware? If you have only 256 files, you can do almost anything and it'll still be fast. Think tens of thousands, at the very least. I like the general idea of this, but I'd advise you not to go overboard with the tool splitting. You can easily have a single "filegrep" tool that includes all queries about size, age and the like, paired with another tree-walking fool. -- \ Troels /\ Henriksen
Re: [dev] alternatives to find for querying the filesystem
On Thu, Dec 12, 2013 at 2:36 PM, Chris Down wrote: > On 2013-12-12 14:32:03 -0500, Andrew Gwozdziewycz wrote: >> So, to find all files in /etc modified within the last hour... >> >> walk /etc | agep -1H - >> >> Or, >> >> walk /etc | xargs agep -1H > > The problem here is speed. For any non-trivial number of files, this > will become non-negligibly slower due to the number of stat family calls > required (and the cost of reinterpreting the data each time). That's a great point, though, the idea would be (as in SQL) to eliminate the most files as soon as possible. The user has some intuition that find doesn't have (unless there's a relative order implemented in find). So, the cost of parsing and reinterpreting things presumably gets smaller and smaller. The number of stat calls of course is duplicated across the pipelines, but again, fewer and fewer each time through. Assume that each filter halves the fileset of, say, 256 files (my /etc directory on this OSX machine has just 247 files). That's less than 512 calls with a few filters. Is that really so bad on modern hardware? -- http://apgwoz.com
Re: [dev] alternatives to find for querying the filesystem
On 2013-12-12 14:32:03 -0500, Andrew Gwozdziewycz wrote: > So, to find all files in /etc modified within the last hour... > > walk /etc | agep -1H - > > Or, > > walk /etc | xargs agep -1H The problem here is speed. For any non-trivial number of files, this will become non-negligibly slower due to the number of stat family calls required (and the cost of reinterpreting the data each time). pgpCh_10pYpXc.pgp Description: PGP signature
[dev] alternatives to find for querying the filesystem
find(1) seems very un-unixy, but it's very powerful. Let's assume for
a minute that find didn't exist. How would you do the following:
1. execute a command for each file (find . -exec whatever {} \;)
2. find files that are > 8M
3. find files that are older than 20 days
4. find all files that are owned by 'joe' that also have execute
permissions for world
Obviously we can write scripts and complicated one liners, but
ultimately it seems as though for most of these things we'd have to
parse output (in some cases convert units) and in general do sucky
things (with the exception of maybe, 1, but ls -R's output isn't easy
to use here)
As a result, does it make sense (or do these already exist?) to have
some of the following:
walk - (implements find $1)
sizep - usage: sizep +Nunit -Nunit =Nunit file1 ..
agep - usage: agep +Nunit -Nunit =Nunit file1 ...
permp - usage: permp {+ | -}{a | u | g | o}{r | s | t | w | x | X | u
| g | o} file1 ...
ownerp - usage: ownp -g -u file1 ...
All of these just print to stdout the names of the files that meet the
requirements, and all of them can read their file names from stdin if
- is given instead of files
So, to find all files in /etc modified within the last hour...
walk /etc | agep -1H -
Or,
walk /etc | xargs agep -1H
Thoughts? Pointers to tools that already do this?
Cheers,
Andrew
--
http://apgwoz.com
Re: [dev] wswsh: a mksh web framework
On 12/12/2013, Troels Henriksen wrote: > No, that was year 100. 2014 is the year of MMXIV. Anyhow, this is actually the year 44.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 11:27 AM, Ryan O’Hara wrote: > Jekyll seems pretty decent to me. What is there to object to? Markdown and > Ruby? > > The rest of the things you mention don’t have much to do with offline > website generation. They’re just languages that compile to other > languages. Jade, especially, is the absolute opposite of a “static > content” language. Jekyll is pretty decent at what it does, I just feel that it is far too overly complex for what it does and is akin to a 10-in-1 fisher price toy. Comparing to this project it seems Jekyll has a couple "advantages" like variables in templates (sed), development tools (start a webserver), build utils (create a Makefile). This is bloat to me. I feel like "web 2.0" developers don't understand the basics and rely on these magic all-in-one tools too much. I don't see how the rest of my list doesn't apply. Browsers can't interpret them so you must generate to something they can offline. On Thu, Dec 12, 2013 at 11:30 AM, Bryan Bennett wrote: > So you're saying that this is better than Coffeescript? That > comparison is completely unintelligible.If you're saying that we > should step back and return to a simpler approach to web > design/development - I completely agree, but how does a static site > generator compare to Coffeescript/LESS/Jade at all? You could very > well extend this to work with all of those technologies. I didn't say that Coffeescript/LESS/Jade directly relate to this project, that was my bit of ranting tacked on :o) These layers come and go so quickly while HTML/Javascript/CSS continue to exist. I'm sure in the month from now we'll see another CSS generator and another Javascript code generator. That is the trend I'm sick of seeing. I know Javascript and CSS very well. I don't need some stupid layer on top of that. If I need to recall some standard methods in my code, I'll use snippets in vim for that.
Re: [dev] wswsh: a mksh web framework
So you're saying that this is better than Coffeescript? That comparison is completely unintelligible.If you're saying that we should step back and return to a simpler approach to web design/development - I completely agree, but how does a static site generator compare to Coffeescript/LESS/Jade at all? You could very well extend this to work with all of those technologies.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 9:23 AM, Nicholas Hall wrote: > On Thu, Dec 12, 2013 at 11:13 AM, Ryan O’Hara wrote: >> On Thu, Dec 12, 2013 at 9:06 AM, Nicholas Hall wrote: >>> On Thu, Dec 12, 2013 at 8:57 AM, YpN wrote: I wrote a shell script using mksh, which generates websites. >>> >>> This looks pretty cool. I'm sick of all the shitty hip offline >>> website generators, and the direction web development is headed in >>> general -- layer upon layer upon layer. Seriously, these guys wrap >>> one shitty language on top of another shitty language. They should >>> leave these tools up to their editors if they feel the need to use >>> them, not standardize another abstraction layer. >>> >> >> I don’t understand how each of your sentences matches up with the rest. >> What are you talking about? > > I'm talking about Jekyll, SASS, Coffeescript, LESS, Compass, Jade. I > could go on. > Jekyll seems pretty decent to me. What is there to object to? Markdown and Ruby? The rest of the things you mention don’t have much to do with offline website generation. They’re just languages that compile to other languages. Jade, especially, is the absolute opposite of a “static content” language.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 11:13 AM, Ryan O’Hara wrote: > On Thu, Dec 12, 2013 at 9:06 AM, Nicholas Hall wrote: >> On Thu, Dec 12, 2013 at 8:57 AM, YpN wrote: >>> I wrote a shell script using mksh, which generates websites. >> >> This looks pretty cool. I'm sick of all the shitty hip offline >> website generators, and the direction web development is headed in >> general -- layer upon layer upon layer. Seriously, these guys wrap >> one shitty language on top of another shitty language. They should >> leave these tools up to their editors if they feel the need to use >> them, not standardize another abstraction layer. >> > > I don’t understand how each of your sentences matches up with the rest. > What are you talking about? I'm talking about Jekyll, SASS, Coffeescript, LESS, Compass, Jade. I could go on.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 9:06 AM, Nicholas Hall wrote: > On Thu, Dec 12, 2013 at 8:57 AM, YpN wrote: >> I wrote a shell script using mksh, which generates websites. > > This looks pretty cool. I'm sick of all the shitty hip offline > website generators, and the direction web development is headed in > general -- layer upon layer upon layer. Seriously, these guys wrap > one shitty language on top of another shitty language. They should > leave these tools up to their editors if they feel the need to use > them, not standardize another abstraction layer. > I don’t understand how each of your sentences matches up with the rest. What are you talking about?
[dev] [tabbed] [PATCH] Allow selecting the colors on command line.
---
Heyho,
When using tabbed for surf the content mostly has a bright background.
When using tabbed for st the terminal at least for me has a dark background.
Since I did not find a color configuration for tabbed which works for both use
cases, I wrote this patch. Since I don't think arg.h allows parameters
consisting of more than one char, I did not use the same parameters as in dmenu.
Instead I used a upper- / lower-case combination.
There were also two missing „break;“ lines in the arg parser, which I fixed.
Regards,
Markus
config.def.h | 8
tabbed.1 | 15 +++
tabbed.c | 18 --
3 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/config.def.h b/config.def.h
index 3a92bd9..ceda9f7 100644
--- a/config.def.h
+++ b/config.def.h
@@ -2,10 +2,10 @@
/* appearance */
static const char font[]= "-*-*-medium-*-*-*-14-*-*-*-*-*-*-*";
-static const char normbgcolor[] = "#22";
-static const char normfgcolor[] = "#cc";
-static const char selbgcolor[] = "#55";
-static const char selfgcolor[] = "#ff";
+static const char* normbgcolor = "#22";
+static const char* normfgcolor = "#cc";
+static const char* selbgcolor = "#55";
+static const char* selfgcolor = "#ff";
static const char before[] = "<";
static const char after[] = ">";
static const int tabwidth = 200;
diff --git a/tabbed.1 b/tabbed.1
index 0ec623e..0ae29ce 100644
--- a/tabbed.1
+++ b/tabbed.1
@@ -70,6 +70,21 @@ with the window id, rather than appending it to the end.
.B \-s
will disable automatic spawning of the command.
.TP
+.BI \-t " color"
+defines the selected background color.
+.IR #RGB ,
+.IR #RRGGBB ,
+and X color names are supported.
+.TP
+.BI \-T " color"
+defines the selected foreground color.
+.TP
+.BI \-u " color"
+defines the normal background color.
+.TP
+.BI \-U " color"
+defines the normal foreground color.
+.TP
.B \-v
prints version information to stderr, then exits.
.SH USAGE
diff --git a/tabbed.c b/tabbed.c
index e870db4..9405644 100644
--- a/tabbed.c
+++ b/tabbed.c
@@ -1197,8 +1197,8 @@ char *argv0;
void
usage(void) {
- die("usage: %s [-dfhsv] [-g geometry] [-n name] [-p [s+/-]pos] "
- "[-r narg] command...\n", argv0);
+ die("usage: %s [-dfhsv] [-g geometry] [-n name] [-p [s+/-]pos] [-r
narg] "
+ "[-u color] [-U color] [-t color] [-T color] command...\n",
argv0);
}
int
@@ -1211,6 +1211,7 @@ main(int argc, char *argv[]) {
case 'c':
closelastclient = True;
fillagain = False;
+ break;
case 'd':
detach = True;
break;
@@ -1242,6 +1243,19 @@ main(int argc, char *argv[]) {
die("tabbed-"VERSION", © 2009-2012"
" tabbed engineers, see LICENSE"
" for details.\n");
+ break;
+ case 't':
+ selbgcolor = EARGF(usage());
+ break;
+ case 'T':
+ selfgcolor = EARGF(usage());
+ break;
+ case 'u':
+ normbgcolor = EARGF(usage());
+ break;
+ case 'U':
+ normfgcolor = EARGF(usage());
+ break;
default:
case 'h':
usage();
--
1.8.2
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 8:57 AM, YpN wrote: > I wrote a shell script using mksh, which generates websites. This looks pretty cool. I'm sick of all the shitty hip offline website generators, and the direction web development is headed in general -- layer upon layer upon layer. Seriously, these guys wrap one shitty language on top of another shitty language. They should leave these tools up to their editors if they feel the need to use them, not standardize another abstraction layer.
Re: [dev] New utility "when"
consider submitting when to the moreutils package On 11 December 2013 11:31, Andrew Gwozdziewycz wrote: > Hey all, > > If you've used watch(1) you know that running a command repeatedly is > useful. What I wished for yesterday though, is for a mechanism that > notified me when a command succeeded, but is long running -- say an > ssh session. > > I wondered if I could do it in shell, but figured it might be too > tricky to do concisely, so I wrote a C program that combines SIGALRM > and SIGCHLD into something that works fairly well (though, I've only > tested it on OS X so far, yeah, I know), but probably murders POSIX > standards (I haven't written Unix C in a while, so my Stevens books > are rusty) > > Anyway, source is on github: https://github.com/apgwoz/when > > Example usage: > > when "make" "xmessage 'that long running build actually worked'" > > (This is no different than a simple while ! `make` ... of course) > > But, using -t is where the "magic" happens. Lets say you're waiting > for a host to come up on AWS or something: > > when -t "ssh user@host" "xmessage 'Connected'" > > When the ssh command finally succeeds, xmessage will pop up saying > 'Connected' and the prompt will still be there. > > Maybe one of you will stop laughing long enough to find it useful. > > Cheers! > > Andrew > > > -- > http://apgwoz.com >
Re: [dev] wswsh: a mksh web framework
sin writes: > On Thu, Dec 12, 2013 at 05:11:06PM +0100, YpN wrote: >> > C is generally more and efficient, I suppose. >> > >> > On 12/12/2013 16:04, sin wrote: >> > > On Thu, Dec 12, 2013 at 03:42:52PM +, Neo Romantique wrote: >> > >> Why Shell, and not C? >> > >> Otherwise tool looks interesting. >> > > I don't see why this has to be done in C. >> >> Actually, I don't know C but I plan to learn it in 2014. >> I might consider porting it to C, for my first practise. I wrote it in mksh >> because this is a wonderful shell and it's really powerful. And it's how I >> learn new shell hacks (creating my stuff) :) > > 2014 is the year of C :) No, that was year 100. 2014 is the year of MMXIV. -- \ Troels /\ Henriksen
Re: [dev] wswsh: a mksh web framework
On 12/12/2013 16:22, sin wrote: On Thu, Dec 12, 2013 at 04:20:32PM +, Neo Romantique wrote: I've meant to write "Generally more readable and efficient", but then after having a second thought I've deleted the readable part, but had some leftover. :) Don't top post. Readable code depends mostly on the programmer. Have you ever written APL code? bye, sin No, I have not. I suppose C-like syntax is easier for me because I've started with Pascal/JS. It's subjective, that is why I've removed it on the second thought. -- Regards, neo~ http://www.inventati.org/neoromance
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 04:20:32PM +, Neo Romantique wrote: > I've meant to write "Generally more readable and efficient", but > then after having a second thought I've deleted the readable part, > but had some leftover. :) Don't top post. Readable code depends mostly on the programmer. Have you ever written APL code? bye, sin
Re: [dev] wswsh: a mksh web framework
I've meant to write "Generally more readable and efficient", but then after having a second thought I've deleted the readable part, but had some leftover. :) On 12/12/2013 16:18, sin wrote: On Thu, Dec 12, 2013 at 11:13:56AM -0500, Strake wrote: On 12/12/2013, Neo Romantique wrote: C is generally more and efficient, I suppose. I assume you mean "more efficient". I think he meant "generally more and efficient" lol -- Regards, neo~ http://www.inventati.org/neoromance
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 11:13:56AM -0500, Strake wrote: > On 12/12/2013, Neo Romantique wrote: > > C is generally more and efficient, I suppose. > > I assume you mean "more efficient". I think he meant "generally more and efficient" lol
Re: [dev] wswsh: a mksh web framework
On 12/12/2013, Neo Romantique wrote: > C is generally more and efficient, I suppose. I assume you mean "more efficient". It may be more for the machine but it's less for the programmer. We build machines to do tedious work so we needn't.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 05:11:06PM +0100, YpN wrote: > > C is generally more and efficient, I suppose. > > > > On 12/12/2013 16:04, sin wrote: > > > On Thu, Dec 12, 2013 at 03:42:52PM +, Neo Romantique wrote: > > >> Why Shell, and not C? > > >> Otherwise tool looks interesting. > > > I don't see why this has to be done in C. > > Actually, I don't know C but I plan to learn it in 2014. > I might consider porting it to C, for my first practise. I wrote it in mksh > because this is a wonderful shell and it's really powerful. And it's how I > learn new shell hacks (creating my stuff) :) 2014 is the year of C :)
Re: [dev] wswsh: a mksh web framework
> C is generally more and efficient, I suppose. > > On 12/12/2013 16:04, sin wrote: > > On Thu, Dec 12, 2013 at 03:42:52PM +, Neo Romantique wrote: > >> Why Shell, and not C? > >> Otherwise tool looks interesting. > > I don't see why this has to be done in C. > > > > -- > Regards, > neo~ > http://www.inventati.org/neoromance Actually, I don't know C but I plan to learn it in 2014. I might consider porting it to C, for my first practise. I wrote it in mksh because this is a wonderful shell and it's really powerful. And it's how I learn new shell hacks (creating my stuff) :) From Y.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 04:05:22PM +, Neo Romantique wrote: > C is generally more and efficient, I suppose. Nonsense. You are just generating text.
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 05:51:44PM +0200, Dimitris Zervas wrote: > That's EXACTLY what I want to do for my blog! I've started the project > but right now it's a piece of crap. > However I use C. I don't even use any markdown library, I am making my > own (I'm not yet sure if that's right or wrong...). Please don't top post, makes it difficult for others to parse the e-mails and to respond properly. bye, sin
Re: [dev] wswsh: a mksh web framework
C is generally more and efficient, I suppose. On 12/12/2013 16:04, sin wrote: On Thu, Dec 12, 2013 at 03:42:52PM +, Neo Romantique wrote: Why Shell, and not C? Otherwise tool looks interesting. I don't see why this has to be done in C. -- Regards, neo~ http://www.inventati.org/neoromance
Re: [dev] wswsh: a mksh web framework
On Thu, Dec 12, 2013 at 03:42:52PM +, Neo Romantique wrote: > Why Shell, and not C? > Otherwise tool looks interesting. I don't see why this has to be done in C.
Re: [dev] New utility "when"
On Thu, Dec 12, 2013 at 10:32 AM, Truls Becken wrote: > On 2013-12-12, at 13:28, Andrew Gwozdziewycz wrote: > >> Are you suggesting that the shell handle the command after the &&? >> Or you let the subshell I spawn do it? > > The shell would handle the command after &&. The command after recognized > arguments is handled using fork + execvp, without a subshell. > >> For the -z mode (default) that could totally work. So, for example: >> >> when cat /file/that/will/eventually/exist && xmessage 'exists' >> >> Instead of running "/bin/sh -c 'cat /file/that/will/eventually/exist'" >> until the exit status is 0 and then running "/bin/sh xmessage >> 'exists'" you just repeatedly run "/bin/sh -c 'cat >> /file/that/will/eventually/exist && xmessage 'exists''" > > Yes, repeat cat until it succeeds. Then return 0 to the shell. > >> I agree that this works, but it's also incorrect because the second >> command must exit with 0, or it'll keep running. I've made the call >> that I don't care about what happens with the second command, only the >> first, and for that reason, that method produces the incorrect >> behavior. > > Huh? The when command exits once, letting the shell call xmessage once. > >> This doesn't work with -t for the simple reason that if you run >> everything after the when token via '/bin/sh -c ...' && waits for the >> first command to finish, which as stated previously is incorrect. > > No. The shell will only let "when" see the stuff before &&. > >> But, I'm pretty sure you had other intentions, and I'm not following >> your thinking. Could you clarify your point? > > > In my mind, when would simply: > > 1) Read all leading elements of argv that start with "-". It does this currently. > 2) Repeatedly fork and exec argv (which now points to a command and its >arguments). Ah, ok. So let the shell do the -z mode. This makes sense. > 3) Return 0 when the child process returns 0, or in the case of -t when the >child process runs long enough. Currently in -t, it waits for the child to finish and returns what the child does (as of last night). > The first part is known as chain loading or Bernstein loading, and is done by > programs such as nice, env, sudo, etc. The only issue I see in the context of > "when" is that the repeated child process will be orphaned in -t mode. I'm calling waitpid to avoid orphaning (though, admittedly, I haven't checked ps to verify) > Perhaps my version should be called "retry" rather than "when". Yeah, retry is a good name for this. Maybe I'll extract the functionality from when later and call it retry. That is, unless you want to write it yourself. Thanks for the suggestions! -- http://apgwoz.com
Re: [dev] wswsh: a mksh web framework
That's EXACTLY what I want to do for my blog! I've started the project but right now it's a piece of crap. However I use C. I don't even use any markdown library, I am making my own (I'm not yet sure if that's right or wrong...). On Thu, Dec 12, 2013 at 5:42 PM, Neo Romantique wrote: > Why Shell, and not C? > Otherwise tool looks interesting. > > > On 12/12/2013 14:57, YpN wrote: >> >> Hey dudes, >> >> I wrote a shell script using mksh, which generates websites. You need to >> write >> your pages / posts in HTML or markdown (the project supports smu) and then >> the script will "create" your website. I know we have werc but I wanted to >> write my own tools. >> Actually it's a bit hard to describe what it does, without examples. >> If you're interested, you can view the project at github[1] >> >> Sincerely >> >> [1] https://github.com/Ypnose/Wswsh >> >> From Y. >> > > -- > Regards, > neo~ > http://www.inventati.org/neoromance > >
Re: [dev] wswsh: a mksh web framework
I think he was aiming for something like werc. Good job! On Thu, Dec 12, 2013 at 10:42 AM, Neo Romantique wrote: > Why Shell, and not C? > Otherwise tool looks interesting. > > > On 12/12/2013 14:57, YpN wrote: >> >> Hey dudes, >> >> I wrote a shell script using mksh, which generates websites. You need to >> write >> your pages / posts in HTML or markdown (the project supports smu) and then >> the script will "create" your website. I know we have werc but I wanted to >> write my own tools. >> Actually it's a bit hard to describe what it does, without examples. >> If you're interested, you can view the project at github[1] >> >> Sincerely >> >> [1] https://github.com/Ypnose/Wswsh >> >> From Y. >> > > -- > Regards, > neo~ > http://www.inventati.org/neoromance > >
Re: [dev] wswsh: a mksh web framework
Why Shell, and not C? Otherwise tool looks interesting. On 12/12/2013 14:57, YpN wrote: Hey dudes, I wrote a shell script using mksh, which generates websites. You need to write your pages / posts in HTML or markdown (the project supports smu) and then the script will "create" your website. I know we have werc but I wanted to write my own tools. Actually it's a bit hard to describe what it does, without examples. If you're interested, you can view the project at github[1] Sincerely [1] https://github.com/Ypnose/Wswsh From Y. -- Regards, neo~ http://www.inventati.org/neoromance
Re: [dev] New utility "when"
On 2013-12-12, at 13:28, Andrew Gwozdziewycz wrote: > Are you suggesting that the shell handle the command after the &&? > Or you let the subshell I spawn do it? The shell would handle the command after &&. The command after recognized arguments is handled using fork + execvp, without a subshell. > For the -z mode (default) that could totally work. So, for example: > > when cat /file/that/will/eventually/exist && xmessage 'exists' > > Instead of running "/bin/sh -c 'cat /file/that/will/eventually/exist'" > until the exit status is 0 and then running "/bin/sh xmessage > 'exists'" you just repeatedly run "/bin/sh -c 'cat > /file/that/will/eventually/exist && xmessage 'exists''" Yes, repeat cat until it succeeds. Then return 0 to the shell. > I agree that this works, but it's also incorrect because the second > command must exit with 0, or it'll keep running. I've made the call > that I don't care about what happens with the second command, only the > first, and for that reason, that method produces the incorrect > behavior. Huh? The when command exits once, letting the shell call xmessage once. > This doesn't work with -t for the simple reason that if you run > everything after the when token via '/bin/sh -c ...' && waits for the > first command to finish, which as stated previously is incorrect. No. The shell will only let "when" see the stuff before &&. > But, I'm pretty sure you had other intentions, and I'm not following > your thinking. Could you clarify your point? In my mind, when would simply: 1) Read all leading elements of argv that start with "-". 2) Repeatedly fork and exec argv (which now points to a command and its arguments). 3) Return 0 when the child process returns 0, or in the case of -t when the child process runs long enough. The first part is known as chain loading or Bernstein loading, and is done by programs such as nice, env, sudo, etc. The only issue I see in the context of "when" is that the repeated child process will be orphaned in -t mode. Perhaps my version should be called "retry" rather than "when". -Truls
Re: [dev] [wiki] Add suckless init
On Thu, Dec 12, 2013 at 10:12:58AM -0500, Strake wrote: > On 12/12/2013, YpN wrote: > > Do you think I could add a section about init? I know ignite and busybox > > init, it might be interesting. > > Rich Felker, author of musl, wrote an init too, but I can't find it now. > > Here is mine, much alike: https://github.com/strake/init/blob/master/init.c nice :)
Re: [dev] [wiki] Add suckless init
On 12/12/2013, YpN wrote: > Do you think I could add a section about init? I know ignite and busybox > init, it might be interesting. Rich Felker, author of musl, wrote an init too, but I can't find it now. Here is mine, much alike: https://github.com/strake/init/blob/master/init.c
Re: [dev] [wiki] Add suckless init
On 12/12/2013, Strake wrote: > Rich Felker, author of musl, wrote an init too, but I can't find it now. Sorry, that ought to be "primary author".
[dev] wswsh: a mksh web framework
Hey dudes, I wrote a shell script using mksh, which generates websites. You need to write your pages / posts in HTML or markdown (the project supports smu) and then the script will "create" your website. I know we have werc but I wanted to write my own tools. Actually it's a bit hard to describe what it does, without examples. If you're interested, you can view the project at github[1] Sincerely [1] https://github.com/Ypnose/Wswsh From Y.
Re: [dev] tinywm: an shorter and cleaner code ?
I've used TinyWMs code to get an idea for how I should begin implementing a wm, but I don't think it's really worth much beyond that. No tags or desktops? No thanks...
Re: [dev] tinywm: an shorter and cleaner code ?
On Thu, Dec 12, 2013 at 2:31 PM, sin wrote: > On Thu, Dec 12, 2013 at 03:23:02PM +0100, patrick295767 patrick295767 wrote: >> […] > What about no window manager? Just run tmux in st. dvtm -- __ Raphaël Proust
Re: [dev] tinywm: an shorter and cleaner code ?
On Thu, Dec 12, 2013 at 03:23:02PM +0100, patrick295767 patrick295767 wrote: > Hi, > > The tinywm is a quite minimal. Tinywm is written in not many lines. > Tinywm works well and is quite basic. > Link: http://packages.debian.org/sid/tinywm > > > So, j ust for fun, what about having a tinier code of the tinywm? What about no window manager? Just run tmux in st.
Re: [dev] [wiki] Add suckless init
> On Thu, Dec 12, 2013 at 08:53:27AM -0500, Bryan Bennett wrote: > > On Thu, Dec 12, 2013 at 8:46 AM, sin wrote: > > > David Galos wrote a small init which you might be interested in. > > > Check it out at: http://galos.no-ip.org/qinit > > > > This looks really interesting. I might try it out this weekend. Thanks for > > the > > link > > > > [1]: https://github.com/hut/minirc > > BTW, I forgot to mention, I think qinit uses some uclibc specific > macros/functions. > It should be trivial to get rid of them though. Thank you guys for your feedback. It's really appreciated. I think I'll edit the "wiki" when we agree about suckless init softwares. Kind regards From Y.
[dev] tinywm: an shorter and cleaner code ?
Hi, The tinywm is a quite minimal. Tinywm is written in not many lines. Tinywm works well and is quite basic. Link: http://packages.debian.org/sid/tinywm So, j ust for fun, what about having a tinier code of the tinywm? Regards, Pat -- For fun: Fermion tiny wm of 10 lines? ;)
Re: [dev] [wiki] Add suckless init
On Thu, Dec 12, 2013 at 08:53:27AM -0500, Bryan Bennett wrote: > On Thu, Dec 12, 2013 at 8:46 AM, sin wrote: > > David Galos wrote a small init which you might be interested in. > > Check it out at: http://galos.no-ip.org/qinit > > This looks really interesting. I might try it out this weekend. Thanks for the > link > > [1]: https://github.com/hut/minirc BTW, I forgot to mention, I think qinit uses some uclibc specific macros/functions. It should be trivial to get rid of them though.
Re: [dev] [wiki] Add suckless init
On Thu, Dec 12, 2013 at 08:53:27AM -0500, Bryan Bennett wrote: > On Thu, Dec 12, 2013 at 8:46 AM, sin wrote: > > The busybox init code is far from pretty. I have not personally looked > > at ignite so I don't know. > > I'm personally using minirc[1] on a number of boxes (which makes use of > busybox's init and busybox's mdev, or some implementation of udev, of > which I've picked eudev over systemd's). You guys might like it. It's > POSIX shell with some interesting choices. Cool, I'll have a look at it. I work on a toy distro[1] mainly for testing sbase + ubase + other interesting ideas. At the moment it uses busybox init with some barebones rc scripts[2] + smdev[3]. > > David Galos wrote a small init which you might be interested in. > > Check it out at: http://galos.no-ip.org/qinit > > This looks really interesting. I might try it out this weekend. Thanks for the > link Beware, I think there are some races in the code. I tried to use it on my distro and it required a considerable amount of hacking before I could get something that worked most of the time. I might be able to dig up my code and send it to you. [1] http://git.2f30.org/morpheus/ [2] http://git.2f30.org/fs/ [3] http://git.2f30.org/smdev/ bye, sin
Re: [dev] [wiki] Add suckless init
Hi, This is definitely correct, - more than correct: "The busybox init code is far from pretty." I would not add it. Furthermore, it is a pretty slow application. On the other hand: Another application: Although the dependencies, I like the code of this application. I believe it is sort of minimal (well, ... except the poppler..) https://github.com/schandinat/green This dependency is the only problem. Pat 2013/12/12 Bryan Bennett : > On Thu, Dec 12, 2013 at 8:46 AM, sin wrote: >> The busybox init code is far from pretty. I have not personally looked >> at ignite so I don't know. > > I'm personally using minirc[1] on a number of boxes (which makes use of > busybox's init and busybox's mdev, or some implementation of udev, of > which I've picked eudev over systemd's). You guys might like it. It's > POSIX shell with some interesting choices. > >> David Galos wrote a small init which you might be interested in. >> Check it out at: http://galos.no-ip.org/qinit > > This looks really interesting. I might try it out this weekend. Thanks for the > link > > [1]: https://github.com/hut/minirc >
Re: [dev] [wiki] Add suckless init
On Thu, Dec 12, 2013 at 8:46 AM, sin wrote: > The busybox init code is far from pretty. I have not personally looked > at ignite so I don't know. I'm personally using minirc[1] on a number of boxes (which makes use of busybox's init and busybox's mdev, or some implementation of udev, of which I've picked eudev over systemd's). You guys might like it. It's POSIX shell with some interesting choices. > David Galos wrote a small init which you might be interested in. > Check it out at: http://galos.no-ip.org/qinit This looks really interesting. I might try it out this weekend. Thanks for the link [1]: https://github.com/hut/minirc
Re: [dev] [wiki] Add suckless init
On Thu, Dec 12, 2013 at 02:35:11PM +0100, YpN wrote: > > Hi, > I often read the "rocks" page on http://suckless.org and > I like it. I found some useful programs. > Do you think I could add a section about init? I know ignite > and busybox init, it might be interesting. The busybox init code is far from pretty. I have not personally looked at ignite so I don't know. David Galos wrote a small init which you might be interested in. Check it out at: http://galos.no-ip.org/qinit The code is not so clean and it is more of a hack but gives you the basic idea. bye, sin
[dev] [wiki] Add suckless init
Hi, I often read the "rocks" page on http://suckless.org and I like it. I found some useful programs. Do you think I could add a section about init? I know ignite and busybox init, it might be interesting. Regards From Y.
Re: [dev] New utility "when"
On Thu, Dec 12, 2013 at 5:16 AM, Truls Becken wrote: > On 2013-12-12 at 04:54, Andrew Gwozdziewycz wrote: > >> On 2013-12-11 at 19:08, Fernando C.V. wrote: >> >>> Sounds like a little nice useful utility, even thoguh I don't like >>> that the commands have to be passed "quoted", as arguments just like >>> that. Not sure if there's a much better way to do it, though. >> >> I was thinking about separating commands with ";" (I thought about --, >> but lots of commands actually use it) which would of course need to be >> escaped in the same way find(1) ends -exec and friends. However, I've >> used find in the past for just this type of thing, so maybe it's not >> the right choice, but the full command can always just be quoted -- >> you'd have to to use pipes anyway, which is certainly common. > > There is another way, as hinted at the beginning of the thread. > > On 2013-12-11 at 18:15, Dimitris Zervas wrote: > >> Instead of passing a second argument, you could return zero and and it in >> shell >> when "command" && echo "yup! :D" > > Unless you want "when" to stay running and finally return the exit code of the > long running process. > > If you go this route, "when" could consume arguments from the beginning of > argv, > and then pass the rest of argv to execvp. > > Your ssh example becomes: > > when -t ssh user@host && xmessage 'Connected' I think I'm missing something. Are you suggesting that the shell handle the command after the &&? Or you let the subshell I spawn do it? For the -z mode (default) that could totally work. So, for example: when cat /file/that/will/eventually/exist && xmessage 'exists' Instead of running "/bin/sh -c 'cat /file/that/will/eventually/exist'" until the exit status is 0 and then running "/bin/sh xmessage 'exists'" you just repeatedly run "/bin/sh -c 'cat /file/that/will/eventually/exist && xmessage 'exists''" I agree that this works, but it's also incorrect because the second command must exit with 0, or it'll keep running. I've made the call that I don't care about what happens with the second command, only the first, and for that reason, that method produces the incorrect behavior. This doesn't work with -t for the simple reason that if you run everything after the when token via '/bin/sh -c ...' && waits for the first command to finish, which as stated previously is incorrect. But, I'm pretty sure you had other intentions, and I'm not following your thinking. Could you clarify your point? -- http://apgwoz.com
Re: [dev] New utility "when"
On 2013-12-12 at 04:54, Andrew Gwozdziewycz wrote: > On 2013-12-11 at 19:08, Fernando C.V. wrote: > >> Sounds like a little nice useful utility, even thoguh I don't like >> that the commands have to be passed "quoted", as arguments just like >> that. Not sure if there's a much better way to do it, though. > > I was thinking about separating commands with ";" (I thought about --, > but lots of commands actually use it) which would of course need to be > escaped in the same way find(1) ends -exec and friends. However, I've > used find in the past for just this type of thing, so maybe it's not > the right choice, but the full command can always just be quoted -- > you'd have to to use pipes anyway, which is certainly common. There is another way, as hinted at the beginning of the thread. On 2013-12-11 at 18:15, Dimitris Zervas wrote: > Instead of passing a second argument, you could return zero and and it in > shell > when "command" && echo "yup! :D" Unless you want "when" to stay running and finally return the exit code of the long running process. If you go this route, "when" could consume arguments from the beginning of argv, and then pass the rest of argv to execvp. Your ssh example becomes: when -t ssh user@host && xmessage 'Connected' -Truls
