On 2014-11-03 14:32, Greg Reagle wrote:
> It occurred to me that environment variables can be used to configure a
> program, instead of programming in a parser or extension language
Things to think over and critique:
http://www.catb.org/esr/writings/taoup/html/ch10s04.html
extern char **environ;
2014-10-29 2:58 GMT-02:00 Louis Santillan :
> Some of the ideas you identified in "rebooting the web" were more
> clearly and concisely conveyed in Ian Hickson's Google+ post [0][1].
Sorry if I wasn't clear or concise enough, but there are points of
Hickson's post that only apply to a certain vis
On Mon, Nov 03, 2014 at 11:31:38PM +0100, FRIGN wrote:
> On Mon, 3 Nov 2014 17:01:13 -0500
> Brandon Mulcahy wrote:
>
> > I'm not advocating a more general approach, however; that minor convenience
> > would be nowhere near worth the headache of having to figure out whether
> > a program is being
On Mon, Nov 03, 2014 at 05:21:20PM -0500, Greg Reagle wrote:
> On Mon, Nov 3, 2014, at 05:14 PM, Martti Kühne wrote:
> > On Mon, Nov 3, 2014 at 10:30 PM, Brandon Mulcahy
> > wrote:
> > > choice (besides doing something like `export option=a; command; export
> > > option=b`). I do wish the concept
On Mon, 3 Nov 2014 17:01:13 -0500
Brandon Mulcahy wrote:
> I'm not advocating a more general approach, however; that minor convenience
> would be nowhere near worth the headache of having to figure out whether a
> program is being invoked by a user or by another program in the general case.
Pars
On Mon, Nov 3, 2014, at 05:14 PM, Martti Kühne wrote:
> On Mon, Nov 3, 2014 at 10:30 PM, Brandon Mulcahy
> wrote:
> > choice (besides doing something like `export option=a; command; export
> > option=b`). I do wish the concept of aliasing were a bit more general.
>
>
> Did you hear of the shell
On Mon, Nov 3, 2014 at 10:30 PM, Brandon Mulcahy wrote:
> choice (besides doing something like `export option=a; command; export
> option=b`). I do wish the concept of aliasing were a bit more general.
Did you hear of the shell feature where you could immediately pass
environment variables by pr
On Mon, Nov 03, 2014 at 10:46:06PM +0100, Markus Teich wrote:
> Brandon Mulcahy wrote:
> > I do wish the concept of aliasing were a bit more general. It'd be nice to
> > be able to have something like it in dmenu without having to resort to
> > wrapper scripts.
>
> What is wrong with having a bina
Heyho,
Brandon Mulcahy wrote:
> Having an option be an environment variable instead of a command-line option
> denies the user that choice (besides doing something like `export option=a;
> command; export option=b`).
You don't need the export.
> I do wish the concept of aliasing were a bit more
Greg Reagle wrote:
> Other programs would not see these variables, other than child processes of
> mutt.
Heyho,
Which could be any editor, attachment viewing program, tunneling tool, process
you pipe a mail to, etc. You should unsetenv(3) them after parsing.
--Markus
One thing I like about command-line options is that you can either specify
them "automatically" via a shell alias or manually. Having an option be an
environment variable instead of a command-line option denies the user that
choice (besides doing something like `export option=a; command; export
opt
On Mon, Nov 3, 2014, at 04:11 PM, Charlie Kester wrote:
> Environment variables are essentially global variables, visible to every
> program and not just the one you want to configure.
Not necessarily. If you set them in .profile or .bashrc or .xsession
then yes, but each program processes its ow
On Mon 03 Nov 2014 at 12:32:25 PDT Greg Reagle wrote:
I just had a thought that might be of interest to fans of the suckless
philosophy.
It occurred to me that environment variables can be used to configure a
program, instead of programming in a parser or extension language into a
program. Are
On Mon, Nov 3, 2014, at 03:21 PM, Dimitris Papastamos wrote:
> Another down-side is that different shells use different syntax for
> setting
> and unsetting environment variables, which can be a PITA if you want
> to share your configuration.
I am just speculating here, a though experiment, but th
On Mon, Nov 3, 2014, at 02:45 PM, FRIGN wrote:
> Not everyone runs his programs from a shell.
Definitely. I wouldn't want that to be a requirement. I would want the
environment to be a tool for implementing run-time configuration, rather
than a user-interface requirement. Whether that is possib
Greg Reagle writes:
> http://suckless.org/conference
> I'd love to see the slides for
> Christian presented runit and ignite and discussed if these systems
> are in line with the suckless philosophy.
http://chneukirchen.org/talks/ignite/chneukirchen2013slcon.pdf
I use this system successfull
On Mon, Nov 3, 2014, at 02:59 PM, Dimitris Papastamos wrote:
> The environment is also of limited size. I think POSIX guarantees a
> space
> of about 2kB iirc for environment variables.
Thanks Dimitris. That would definitely be a disadvantage.
> This approach also does not scale in general as p
On Mon, Nov 03, 2014 at 02:32:25PM -0500, Greg Reagle wrote:
> I just had a thought that might be of interest to fans of the suckless
> philosophy.
>
> It occurred to me that environment variables can be used to configure a
> program, instead of programming in a parser or extension language into a
On Mon, Nov 03, 2014 at 02:32:25PM -0500, Greg Reagle wrote:
> ...
> variables. Do you know of any programs that do this? I assume there
> ...
Greg, bs[0] is a nice little script[1] that makes setting up a config
file with environment variables a breeze!
There's also envdir[2] from daemontools.
On Mon, Nov 03, 2014 at 07:59:14PM +, Dimitris Papastamos wrote:
> For run-time configuration I'd opt for command line options or if that is
> not enough, I'd go for a simple configuration file. There are legitimate
> cases where config.h is simply not enough or not applicable. Think of
> a l
On Mon, Nov 03, 2014 at 02:32:25PM -0500, Greg Reagle wrote:
> I just had a thought that might be of interest to fans of the suckless
> philosophy.
>
> It occurred to me that environment variables can be used to configure a
> program, instead of programming in a parser or extension language into a
On Mon, 3 Nov 2014 08:37:24 -0500
Augusto Born de Oliveira wrote:
> Yeah, I used that for a bit, but then st has a doubly-thick border in
> the bottom and right edges, as opposed to centering content within its
> window. Totally cosmetic and kind of OCD, but it bothers me! =)
You must be crazy.
On Mon, 03 Nov 2014 14:32:25 -0500
Greg Reagle wrote:
> It occurred to me that environment variables can be used to configure a
> program, instead of programming in a parser or extension language into a
> program. Are there any reasons not to just use environment variables?
> Then a rc file cou
On Mon, Nov 3, 2014, at 02:37 PM, Markus Teich wrote:
> you still have to parse the contents of the environment variables
> compared to
> static compiled in configuration as in config.h.
That's true and that's a good point, but I am interested in discussing
environment variables as a form of *run-
Greg Reagle wrote:
> It occurred to me that environment variables can be used to configure a
> program, instead of programming in a parser or extension language into a
> program. Are there any reasons not to just use environment variables? Then a
> rc file could just be a shell script that sets e
http://suckless.org/conference
I'd love to see the slides for
Christian presented runit and ignite and discussed if these systems
are in line with the suckless philosophy.
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
I just had a thought that might be of interest to fans of the suckless
philosophy.
It occurred to me that environment variables can be used to configure a
program, instead of programming in a parser or extension language into a
program. Are there any reasons not to just use environment variables?
Hi,
>
> I agree with you in some things, but I don't think this the proper
> place where discuss this point. The decision should be taken by a
> group of terminal developers, so I suggust you try to create a way
> developers can discuss about it (some kind of news group or a mailing
> list), and
On Sun, Nov 2, 2014, at 17:24, Michael Forney wrote:
> I found quite a lot of bugs, so I ended up pretty much rewriting as I
> followed the spec¹.
How about +X? I noticed there were no test cases for that.
+X acts like +x provided either the file is a directory or the file
already has at least on
> >> resizehints = False;
Yeah, I used that for a bit, but then st has a doubly-thick border in
the bottom and right edges, as opposed to centering content within its
window. Totally cosmetic and kind of OCD, but it bothers me! =)
Turning off resizehints also causes weird rendering bugs with mpla
On Sun, 2 Nov 2014 20:24:39 -0500
Augusto Born de Oliveira wrote:
> I wrote a patch -- intended for the optional patches section on the site --
> that makes st resizable to the pixel, as opposed to the nearest char
> width/height. This is to avoid the gaps between and around terminals in
> tiling
>> HOME must hold the value of the user's home directory, if this
>> value is not the value of /etc/passwd then you have an error
>> in your configuration. The same can be said about SHELL. You
>> can change your shell selection using chsh.
>
> I don't agree with your interpretation of the POSIX
Hi,
>>> Above my opinion might be not constructive, so now I propose alternate
>>> sequences:
>>>
>>> I recommend a recall of Konsole style truecolor control seqences, and
>>> propose to change them as follows:
>>>
>>> CSI 38 ; 2 ; Pr ; Pg ; Pb m -> CSI ? Pr ; Pg ; Pb $ m
>>> CSI 48 ; 2 ; P
Applied both of them, thanks for fixing this! :)
> Hi folks,
>
> my delete-key behaves as backspace since commit
> 9d9e049eac3dacb2725f9d792f7cdd2230062313 on all my linux machines
> (debian, fedora, ubuntu) and openbsd.
> i had this problem in the past (and wrote to this list about it), and
> my .zshrc since then contains stty erase ^H:
35 matches
Mail list logo
