Re: [dev] [sbase] chvt.c does not need to be executable
tcc can execute .c files On Jun 26, 2013, at 0:43, u...@netbeisser.de wrote: > On Tue, Jun 25, 2013 at 11:56:27PM +0200, Jakob Kramer wrote: >> u...@netbeisser.de wrote: >>> On Tue, Jun 25, 2013 at 08:24:08PM +0200, Jakob Kramer wrote: so why keep it executable... commit 8512381861878f2123a50a162a0d1ea550157da5 Author: Jakob Kramer Date: Tue Jun 25 20:10:39 2013 +0200 removed executable bits from chvt.c diff --git a/chvt.c b/chvt.c old mode 100755 new mode 100644 >>> Thanks for catching this. It could have harmed?: >> Well, I don't think anyone would have tried to execute chvt.c, but >> it is unnecessary / wrong. > > Well agreed on your part. But, you never know. I was thinking of something > like cgit, executing it. >
[dev] Gmail watcher from commandline
Hi, excuse me for the bad English... I created a simple gmail watcher
script/solution, because the gmail watcher extension to the Firefox no more
developed.
Gmail Watcher — without Firefox, from commandline!
Under Sabayon distro:
emerge fetchmail
To the $HOME/.fetchmailrc file:
poll imap.gmail.com port 993 protocol IMAP username "usern...@gmail.com"
password "MySecretPassword" keep ssl
Create a script:
#! /bin/bash
UZENET=`fetchmail -f /home/vz/.fetchmailrc --check | tr "(" " " | tr ")" "
" | sed 's/ \+/ /g'`
OSSZESEN=`echo "$UZENET" | cut --delimiter=" " -f1`
OLVASOTT=`echo "$UZENET" | cut --delimiter=" " -f3`
OLVASATLAN=`expr $OSSZESEN - $OLVASOTT`
if [[ $OLVASATLAN != 0 ]] ; then
ogg123 -q /Programs/Szkriptjeim/audio/ApuciLeveledJott_hangosabb.ogg
fi
Save this script to a good place, for ekzample to the
/Programs/Szkriptjeim/0.0.0/bin/levelemjott
chmod this file as executable.
As root:
gpasswd -a YourUserName cron
gpasswd -a YourUserName crontab
Create a simple text file, with this line:
*/2 * * * * /Programs/Szkriptjeim/0.0.0/bin/levelemjott
The */2 means, that the script check your emails in every 2 minutes.
Create a $HOME/cron directory, and save into them this textfile above, with
name: "levelemjott".
Write to the $HOME/.xinitrc this line:
crontab /home/YourUserName/cron/levelemjott
Reboot, and enjoy!
Re: [dev] Re: Maintaining sbase
On 25/06/2013, Martti Kühne wrote: > On Tue, Jun 25, 2013 at 4:58 PM, Calvin Morrison > wrote: >> my votes are for at a minimum are for: >> >> sponge >> tee >> pee > > And a cloth to clean up the mess... No, that's what sponge is for.
Re: [dev] [sbase] sponge
> Except it does not actually sponge in the stdout case, only when > writing to file. Perhaps it would be better to drop support for stdout? > Or cat temp file to stdout at the end? Why does it open a temp file > when not using it? Definitely drop stdout support, its existence makes no sense. To keep the code simple, I suggest a read-write temp copy, rather than ever using rename.
Re: [dev] [sbase] chvt.c does not need to be executable
On Tue, Jun 25, 2013 at 11:56:27PM +0200, Jakob Kramer wrote: > u...@netbeisser.de wrote: > >On Tue, Jun 25, 2013 at 08:24:08PM +0200, Jakob Kramer wrote: > >>so why keep it executable... > >>commit 8512381861878f2123a50a162a0d1ea550157da5 > >>Author: Jakob Kramer > >>Date: Tue Jun 25 20:10:39 2013 +0200 > >> > >> removed executable bits from chvt.c > >> > >>diff --git a/chvt.c b/chvt.c > >>old mode 100755 > >>new mode 100644 > >Thanks for catching this. It could have harmed?: > Well, I don't think anyone would have tried to execute chvt.c, but > it is unnecessary / wrong. Well agreed on your part. But, you never know. I was thinking of something like cgit, executing it.
Re: [dev] [sbase] chvt.c does not need to be executable
u...@netbeisser.de wrote: On Tue, Jun 25, 2013 at 08:24:08PM +0200, Jakob Kramer wrote: so why keep it executable... commit 8512381861878f2123a50a162a0d1ea550157da5 Author: Jakob Kramer Date: Tue Jun 25 20:10:39 2013 +0200 removed executable bits from chvt.c diff --git a/chvt.c b/chvt.c old mode 100755 new mode 100644 Thanks for catching this. It could have harmed?: Well, I don't think anyone would have tried to execute chvt.c, but it is unnecessary / wrong.
Re: [dev] [sbase] chvt.c does not need to be executable
On Tue, Jun 25, 2013 at 08:24:08PM +0200, Jakob Kramer wrote: > so why keep it executable... > commit 8512381861878f2123a50a162a0d1ea550157da5 > Author: Jakob Kramer > Date: Tue Jun 25 20:10:39 2013 +0200 > > removed executable bits from chvt.c > > diff --git a/chvt.c b/chvt.c > old mode 100755 > new mode 100644 Thanks for catching this. It could have harmed?: ,chmod +x chvt.c ,./chvt.c ./chvt.c: line 10: enum: command not found ./chvt.c: line 11: linux/vt.h: No such file or directory ./chvt.c: line 12: VT_ACTIVATE: command not found ./chvt.c: line 13: VT_WAITACTIVE: command not found ./chvt.c: line 14: linux/kd.h: No such file or directory ./chvt.c: line 15: KDGKBTYPE: command not found ./chvt.c: line 16: syntax error near unexpected token `}' ./chvt.c: line 16: `};'
Re: [dev] Re: Maintaining sbase
On Tue, Jun 25, 2013 at 4:58 PM, Calvin Morrison wrote: > my votes are for at a minimum are for: > > sponge > tee > pee And a cloth to clean up the mess...
Re: [dev] dwm: native window tabs
Thanks for your answer. I'll post it to the wiki, Philippe. - Mail original - De: "Andrew Hills" À: dev@suckless.org Envoyé: Mardi 25 Juin 2013 22:00:06 Objet: Re: [dev] dwm: native window tabs On Tue, 25 Jun 2013 21:57:44 +0200 (CEST) philippe.g...@free.fr wrote: > If people are interested I can send the patch. Let me know if I > should post it directly to this mailing list. You should post it to the wiki. That is the standard procedure for sharing patches.
Re: [dev] dwm: native window tabs
On Tue, 25 Jun 2013 16:00:27 -0400 Jacob Todd wrote: > Have you not heard of tabbed? Perhaps you should read his mail. signature.asc Description: PGP signature
Re: [dev] dwm: native window tabs
Have you not heard of tabbed?
Re: [dev] dwm: native window tabs
On Tue, 25 Jun 2013 21:57:44 +0200 (CEST) philippe.g...@free.fr wrote: > If people are interested I can send the patch. Let me know if I > should post it directly to this mailing list. You should post it to the wiki. That is the standard procedure for sharing patches. signature.asc Description: PGP signature
[dev] dwm: native window tabs
Hello, I wrote a patch to add a bar in dwm with a tab displayed for each window. It is especially interesting in monocle mode, transforming this mode in a "tab" mode. Navigating from window to window can be done by clicking on the window tabs or using the usual Mod1-j/k keys. I am using this feature in particular with mupdf when opening many files, it can also be particularly useful when using surf for web browsing. It's an alternative, which I found more practical and flexible, to the ''tabbed'' application. If people are interested I can send the patch. Let me know if I should post it directly to this mailing list. Regards, Philippe.
Re: [dev] [sbase] sponge
[2013-06-25 20:22] Jakob Kramer
>
> I wrote a sponge program, but I am not fully convinced of it yet. What
> do you think?
I think you shouldn't rename(2). Renaming a file and replacing it's
contents are quite different things. Take for example:
$ mkdir a
$ chmod 600 a/b
$ touch a/b
$ chmod 100 a
$ echo foo >a/b# this goes well
$ echo bar >c
$ mv c a/b# this not
mv: cannot move `c' to `a/b': Permission denied
Special permissions and owner/group-ships are lost as well.
Either keep the contents in memory or read-write the contents
back.
Or better use what's already available: sort(1).
#!/bin/sh
if $# -ne 1 ; then
echo "Usage: ${0##*/} outfile" >&2
exit 1
fi
sort -m -o "$1"
;-)
meillo
Re: [dev] [sbase] sponge
On 2013-06-25, at 20:39, Calvin Morrison wrote: > sponge sucks up stdin, waits till it is closed then puts it out to stdout Except it does not actually sponge in the stdout case, only when writing to file. Perhaps it would be better to drop support for stdout? Or cat temp file to stdout at the end? Why does it open a temp file when not using it? From a manpage found somewhere on the net: It also creates the output file atomically by renaming a temp file into place, and preserves the permissions of the output file if it already exists. If the output file is a special file or symlink, the data will be written to it. The two last bits are not so in the proposed sbase version. Should they be? -Truls
Re: [dev] [sbase] sponge
On 25 June 2013 14:34, Galos, David wrote: > Isn't this just 'tee [file] > /dev/null'? > No. sponge sucks up stdin, waits till it is closed then puts it out to stdout
Re: [dev] [sbase] sponge
Isn't this just 'tee [file] > /dev/null'?
[dev] [sbase] chvt.c does not need to be executable
so why keep it executable... commit 8512381861878f2123a50a162a0d1ea550157da5 Author: Jakob Kramer Date: Tue Jun 25 20:10:39 2013 +0200 removed executable bits from chvt.c diff --git a/chvt.c b/chvt.c old mode 100755 new mode 100644
[dev] [sbase] sponge
Hi!
I wrote a sponge program, but I am not fully convinced of it yet. What
do you think?
Regards,
Jakob Kramer
commit 3565860b40ea4a8220d5029e3d74b437a9205cda
Author: Jakob Kramer
Date: Tue Jun 25 19:55:37 2013 +0200
added sponge
diff --git a/Makefile b/Makefile
index 9aeb5c4..7f91bac 100644
--- a/Makefile
+++ b/Makefile
@@ -61,6 +61,7 @@ SRC = \
sleep.c\
sort.c \
split.c\
+ sponge.c \
sync.c \
tail.c \
tee.c \
diff --git a/sponge.1 b/sponge.1
new file mode 100644
index 000..8c09cc7
--- /dev/null
+++ b/sponge.1
@@ -0,0 +1,11 @@
+.TH SPONGE 1 sbase\-VERSION
+.SH NAME
+sponge \- soak up standard input and write to a file
+.SH SYNOPSIS
+.B sponge
+.RI [ file ]
+.SH DESCRIPTION
+.B sponge
+reads stdin and writes to the specified file or stdout otherwise. This
+makes it possible to easily create pipes which read from and write to
+the same file.
diff --git a/sponge.c b/sponge.c
new file mode 100644
index 000..c116905
--- /dev/null
+++ b/sponge.c
@@ -0,0 +1,46 @@
+/* See LICENSE file for copyright and license details. */
+#include
+
+#include "util.h"
+
+int
+main(int argc, char *argv[])
+{
+ FILE *fp, *tmpfp;
+ char *tmp_nam, buf[BUFSIZ];
+ size_t n;
+
+ ARGBEGIN {
+ default:
+ eprintf("usage: %s [file]\n", argv0);
+ } ARGEND;
+
+ if(argc == 0)
+ /* maybe itâs better to just redirect stdin > stdout
+ * directly, in this case */
+ fp = stdout;
+ else if(argc == 1)
+ if(!(fp = fopen(argv[0], "w")))
+ eprintf("fopen %s:", argv[0]);
+
+ if(!(tmp_nam = tmpnam(NULL)))
+ eprintf("tmpnam:");
+
+ if(!(tmpfp = fopen(tmp_nam, "w")))
+ eprintf("fopen %s:", tmp_nam);
+
+ while((n = fread(buf, 1, sizeof buf, stdin)) > 0) {
+ if(fwrite(buf, 1, n, (fp == stdout ? stdout : tmpfp)) != n)
+ eprintf("%s: write error:", buf);
+ }
+
+ if(fp != stdout)
+ if(rename(tmp_nam, argv[0])) {
+ eprintf("could not create file:");
+ fclose(fp);
+ }
+
+ fclose(tmpfp);
+
+ return 0;
+}
Re: [dev] Re: Maintaining sbase
busybox ash.
Re: [dev] Re: Maintaining sbase
my votes are for at a minimum are for: sponge tee pee On 25 June 2013 10:54, Daniel Bryan wrote: >> first of all, some things in moreutils would be awesome > > Especially if they weren't written in Perl.
Re: [dev] Re: Maintaining sbase
> first of all, some things in moreutils would be awesome Especially if they weren't written in Perl.
Re: [dev] Re: Maintaining sbase
Am 2013-06-25 16:42, schrieb Jesse Ogle: I understood sbase to have a loose correspondence to coreutils. Is this the case? Coreutils does not have a shell, or am I wrong about that? I don't think „Everyone is doing it this way“ is a valid argument in any discussion. On Tue, Jun 25, 2013 at 8:58 AM, Galos, David wrote: The shell is a topic around which there is far too much religion. Sbase should not include a shell. This however is a good argument. --Markus
Re: [dev] Re: Maintaining sbase
On 25 June 2013 10:45, Chris Down wrote: > On 25 June 2013 22:42, Jesse Ogle wrote: >> I understood sbase to have a loose correspondence to coreutils. Is >> this the case? Coreutils does not have a shell, or am I wrong about >> that? > > GNU coreutils has no shell, it is packaged separately (as GNU bash). > Are we determining ourselves based upon GNU, instead of what is logical or better? first of all, some things in moreutils would be awesome
Re: [dev] Re: Maintaining sbase
On 25 June 2013 22:42, Jesse Ogle wrote: > I understood sbase to have a loose correspondence to coreutils. Is > this the case? Coreutils does not have a shell, or am I wrong about > that? GNU coreutils has no shell, it is packaged separately (as GNU bash).
Re: [dev] Re: Maintaining sbase
I understood sbase to have a loose correspondence to coreutils. Is this the case? Coreutils does not have a shell, or am I wrong about that? Jesse On Tue, Jun 25, 2013 at 10:17 AM, Calvin Morrison wrote: > why not rc? > > On 25 June 2013 10:10, Carlos Torres wrote: >> On Tue, Jun 25, 2013 at 8:58 AM, Galos, David >> wrote: What is your opinion on a shell for sbase? >>> >>> The shell is a topic around which there is far too much religion. >>> Sbase should not include a shell. >>> >> >> :) i like this answer >> >
Re: [dev] Re: Maintaining sbase
why not rc? On 25 June 2013 10:10, Carlos Torres wrote: > On Tue, Jun 25, 2013 at 8:58 AM, Galos, David > wrote: >>> What is your opinion on a shell for sbase? >> >> The shell is a topic around which there is far too much religion. >> Sbase should not include a shell. >> > > :) i like this answer >
Re: [dev] Re: Maintaining sbase
On Tue, Jun 25, 2013 at 8:58 AM, Galos, David wrote: >> What is your opinion on a shell for sbase? > > The shell is a topic around which there is far too much religion. > Sbase should not include a shell. > :) i like this answer
Re: [dev] Re: Maintaining sbase
> What is your opinion on a shell for sbase? The shell is a topic around which there is far too much religion. Sbase should not include a shell.
Re: [dev] Re: Maintaining sbase
[2013-06-25 13:02] Christian Neukirchen > Chris Down writes: > > > On 25 June 2013 18:01, Christian Neukirchen wrote: > >> pmarin writes: > >> > >>> dash has a broken builtin echo command and they are not interested in > >>> fix it. I think busybox ash fixed the problem. > >>> > >>> dash> echo '\tshit' > >>> shit > >>> ash> echo '\tshit' > >>> \tshit > >> > >> That is bad indeed. Know any other problems? > > > > It lacks in almost every way that you would want from a > > user-customisable REPL environment. > > I'm not trying to find a interactive shell. AFAIK dash was never meant to be an interactive shell. meillo
[dev] Re: Maintaining sbase
Chris Down writes: > On 25 June 2013 18:01, Christian Neukirchen wrote: >> pmarin writes: >> >>> dash has a broken builtin echo command and they are not interested in >>> fix it. I think busybox ash fixed the problem. >>> >>> dash> echo '\tshit' >>> shit >>> ash> echo '\tshit' >>> \tshit >> >> That is bad indeed. Know any other problems? > > It lacks in almost every way that you would want from a > user-customisable REPL environment. I'm not trying to find a interactive shell. -- Christian Neukirchenhttp://chneukirchen.org
Re: [dev] Re: Maintaining sbase
Chris Down dixit: >try mksh. FWIW, mksh has three different “echo”; if invoked as mksh, it uses a BSD echo by default which does interpret backslashes, but if one uses set -o posix (or invokes it as sh or -sh and it is compiled with -DMKSH_BINSHPOSIX (CVS HEAD)) it has an echo that only honours -n as first argument and doesn’t do anything else (Debian Policy §10.4). bye, //mirabilos -- [DJBDNS Zone] TTL 86400 – kann man da auch 1d schreiben? nö, außerdem kann ein Deutscher oder ein Japaner mit 1d ja erstmal nix anfangen, oder könntest du 1日 im zone file lesen? das heißt für mich: ein Regal, das u.U. schiefstehen könnte
Re: [dev] Re: Maintaining sbase
Quoth pmarin: > dash has a broken builtin echo command and they are not interested in > fix it. I think busybox ash fixed the problem. Is it really broken? I got the impression from [0] that echo was so badly specified that one shouldn't trust it to do much at all, though I confess I haven't read the specs; maybe it's just mis- implemented widely. 0. http://www.etalabs.net/sh_tricks.html
Re: [dev] Re: Maintaining sbase
On 25 June 2013 18:01, Christian Neukirchen wrote: > pmarin writes: > >> dash has a broken builtin echo command and they are not interested in >> fix it. I think busybox ash fixed the problem. >> >> dash> echo '\tshit' >> shit >> ash> echo '\tshit' >> \tshit > > That is bad indeed. Know any other problems? It lacks in almost every way that you would want from a user-customisable REPL environment. If you want a sane alternative, try mksh.
[dev] Re: Maintaining sbase
pmarin writes: > dash has a broken builtin echo command and they are not interested in > fix it. I think busybox ash fixed the problem. > > dash> echo '\tshit' > shit > ash> echo '\tshit' > \tshit That is bad indeed. Know any other problems? -- Christian Neukirchenhttp://chneukirchen.org
Re: [dev] Re: Maintaining sbase
dash has a broken builtin echo command and they are not interested in fix it. I think busybox ash fixed the problem. dash> echo '\tshit' shit ash> echo '\tshit' \tshit On Mon, Jun 24, 2013 at 11:32 PM, Christian Neukirchen wrote: > Markus Teich writes: > >> What is your opinion on a shell for sbase? > > I had a look at dash, which is sh-compatible and fairly small, and the > code did not look half as bad as I expected it to be. > > -- > Christian Neukirchenhttp://chneukirchen.org > >
