Re: [dev] Reasonable Makefiles
> So the Makefile has this: > > all: autoconfig $(BIN) > > autoconfig: > sh config.uname >> config.mk > touch $@ > > and config.uname is a shell script along these lines: > > #!/bin/sh > > os=`uname` > > case $os in > Darwin ) > echo 'Configuring for Darwin' >&2 > echo '# Extra configuration for Darwin (from config.uname)' > echo 'EXTRA_CPPFLAGS = -I/opt/local/include' > ;; > esac > It is similar to the configure of utmp, and usually it is the only thing you need. Regards, -- Roberto E. Vargas Caballero
Re: [dev] Reasonable Makefiles
Quoth Nick: > Basically because I'm replacing a autotools horrorshow with > plain make, but am not sure what the nicest way of allowing compile- > time feature disabling is. Can 'ifdef' be relied upon, and does it > tend to produce unreadable and buggy makefiles in anyone's > experience? Are there other options, beyond asking people to comment > out certain lines in a config.mk, to e.g. disable some LDFLAGS? So I changed my goal slightly to just do basic build variable adjustments based on the system. I ended up creating a bourne script called config.uname, which sets a few sensible defaults for weird systems (like OSX & solaris), and appends them to the config.mk, on first compilation. So that they can still be changed by editing config.mk if you want, and they're not hidden away in some 'ifeq' using included Makefile. So the Makefile has this: all: autoconfig $(BIN) autoconfig: sh config.uname >> config.mk touch $@ and config.uname is a shell script along these lines: #!/bin/sh os=`uname` case $os in Darwin ) echo 'Configuring for Darwin' >&2 echo '# Extra configuration for Darwin (from config.uname)' echo 'EXTRA_CPPFLAGS = -I/opt/local/include' ;; esac It seems to me like a pretty reasonable and usable way of doing some basic autoconfiguration for different systems. Comments, anyone? Nick
Re: [dev] Shell vs C where is the border?
On Mon, 10 Mar 2014 20:39:08 +0100 Szymon Olewniczak wrote: > But having so many individual programs is more harder to use that just > one (we need to run more commands), so reasonable would be to combine > all this commands to one script which would do all this work > automaticaly. So what solution would be better in your opinion? When > we should use shell scripts and when write new C programs to achieve > our goals? My mail probably will be bounced, but anyway. It (pipes or lack of them) can be abused either way. Example of way too many command line flags (GNU ls): $ ls --help | awk '/^ {2,6}-/{i++} END{print i}' 58 Yet you won't likely use more than a dozen options offered by ls ever (and fewest on daily basis). Those rare cases, when you need something specialized could be solved by sed/awk and other filters. Still they somehow managed to squeeze all those flags there - someone really hates pipes. Counter example would be man(1) command (this is personal opinion). Some implementation are doing something similar to that: $ zcat some-manpage.1.gz | eqn | grap | pic | tbl | vgrind | refer \ | troff | more This is running every time when you type "man some-manpage". Filter approach of *roff made sense, when it was used for creating documents for printing (and it was often most CPU intensive command on the box according to some accounts). -- Paul Onyschuk
Re: [dev] Shell vs C where is the border?
Szymon Olewniczak writes: > But having so many individual programs is more harder to use that just > one (we need to run more commands), so reasonable would be to combine > all this commands to one script which would do all this work > automaticaly. So what solution would be better in your opinion? When > we should use shell scripts and when write new C programs to achieve our > goals? Most shells typically have a mixture of the bad points of the "new" languages, and the more traditional, "old" languages: - Not expressive - Interpreted - No typing system (or rudimentary) - Extremely rudimentary programming constructs Use shell scripts to piece together tools for common tasks. They should really only be used in a few cases: - Acting as a wrapper for rudimentary IPC - Manipulating file hierarchies - Manipulating files and streams (not the shell, but sed/awk are typically available) - Launching other programs These are things that are well implemented in the shell, and don't suffer from many of the caveats that permeate most modern shells. Almost all other use of the shell, in my opinion, is wrong. Use another programming language for anything that is even remotely invested. Things which look correct are often wrong for subtle, bug-inducing reasons (often compatibility reasons). The POSIX shell in particular has some insane default actions, some of which cannot be fixed in a POSIX shell alone. Think hard before you use a (POSIX-y) shell script to do your bidding. pgpB7qIP1VzCl.pgp Description: PGP signature
Re: [dev] Shell vs C where is the border?
On Mon, Mar 10, 2014 at 12:39 PM, Szymon Olewniczak wrote: > So what solution would be better in your opinion? When > we should use shell scripts and when write new C programs to achieve our > goals? When it makes sense.
[dev] Shell vs C where is the border?
Hi, I was recetly wondering about the use cases of C and shell. I've seen that this topic appears several times mostly when discussing sbase. Some of you probably knows ffmpeg, software that allows to convert media files between various formats. Imagine now that we have several smaller tools that do one thing and do it well and to convert mkv wideo do webm we do: videostream movie.mkv | theoradec | v8enc > video audiostream movie.mkv > audio createwebmvideo video audio But having so many individual programs is more harder to use that just one (we need to run more commands), so reasonable would be to combine all this commands to one script which would do all this work automaticaly. So what solution would be better in your opinion? When we should use shell scripts and when write new C programs to achieve our goals? BR, Szymon
Re: [dev] Screencasts?
> Pay attention when things seem too slow or, in your words, feel too > clunky. That's telling you there's a rough edge you need to smooth > down. But once it's fixed and no longer bothering you, there's really > no need to go on fussing over it. > I'll echo that, but suggest that maybe what you are looking for in that particular scenario is bookmarks.
Re: [dev] Screencasts?
On Mon 10 Mar 2014 at 09:29:16 PDT Charlie Kester wrote: Pay attention when things seem too slow or, in your words, feel too clunky. That's telling you there's a rough edge you need to smooth down. But once it's fixed and no longer bothering you, there's really no need to go on fussing over it. Unless, of course, you're a dedicated knob-polisher like the rest of us. ;)
Re: [dev] Screencasts?
On Sun 09 Mar 2014 at 12:54:11 PDT Caleb Malchik wrote: I switched to Linux/cli/dwm from OS X just a few years ago, and since the switch I feel the way I do certain basic things is embarrassingly inefficient. For example, if I find an article on the web I want to come back to, I will copy the URL from the address bar, open a terminal window with ctl-shift-enter, type 'vi doc/toread', then paste the URL at the top of the file. Yes it's still faster than what I would have done on OS X, but it feels clunky. I know enough to come up with my own fixes for a lot of these inefficiencies, but I wouldn't be confident that such fixes are sensible, and that there isn't a simpler and functionally better solution. And the amount of documentation I would have to read to be confident that my own solutions are sensible seems overwhelming. I'm not going to go down the screencast rathole. Instead, I'll simply point out that the steps you described are scriptable. Find out how to get the current url from your browser in a script. Also how to add a line to the beginning of a file (adding it to the end is easier.) If your browser doesn't support a custom hotkey you can use to invoke your script, create one at the system level. The latter choice will probably require you to find a way to identify and query the running instance of the browser. If your browser doesn't support any of this, or if it makes it too difficult, you might want to count that as a reason to drop it in favor of one that is more tractable. (Try surf, or uzbl!) That's probably the best way to evaluate software: does it allow you to quickly knock together solutions to accomplish custom tasks like this? The Unix philosophy is that the software which best supports this kind of ad hoc programming is software that is simple: designed to do one thing and do it well. But it's also software that is *composable*. If you seek out and use software that reflects this philosophy, you'll get the kind of efficiency you want almost automagically. But beware the siren song of ultimate efficiency! The Unix approach isn't about achieving perfection, it's about getting the job done. And that means good enough is usually good enough. Pay attention when things seem too slow or, in your words, feel too clunky. That's telling you there's a rough edge you need to smooth down. But once it's fixed and no longer bothering you, there's really no need to go on fussing over it. The idea that someone else might have found a more 'sensible' or more elegant solution should only concern you if what you've put together on your own still doesn't feel right.
Re: [dev] Screencasts?
On Mon, Mar 10, 2014 at 6:33 AM, Christoph Lohmann <2...@r-36.net> wrote: > Stop spreading this screencast crap. Use some expressive > language, maybe a screenshot and _text_ to describe what you are doing. > This is easier to read, can be easier stored, searched / grepped, trans‐ > lated, changed, extended and added to the suckless wiki. Agreed. Screencasts are not suckless.
Re: [dev] Screencasts?
Kai Hendry said: > Videos should be easier to store (if they are self-contained), create > and consume. Videos are harder to store (they are a lot larger then every other type of content), to create (video codecs are very bad at encoding text) and - the hardest part - to consume (you need to either memorize the whole process or enter infinite "play - skip backwards - pause" cycle to follow instructions). It only pays of for very UI-heavy software with tricky interaction and "low discoverability" of UI elements, but even then screenshots normally do better. Effectively the only good cases for screencasts I've seen to date are video games and Metro UI. > Anyway, there is room for both mediums. Suckless software workflow is much easier to describe in plain text. If there is any room for screencasting, it definitely isn't here. -- Dmitrij D. Czarkoff