Re: [dev] [stest] Hidden file processing

2017-10-07 Thread Kamil Cholewiński
On Sat, 07 Oct 2017, Hiltjo Posthuma wrote: > I think this is still not clear: what if a file is hidden due to its path? > for example: $HOME/.config/somefile > > should it be visible or not? > > the stest man page uses the term "file" but "path" is meant. > for example: >

Re: [dev] [stest] Hidden file processing

2017-10-07 Thread Hiltjo Posthuma
On Sat, Oct 07, 2017 at 11:54:05AM +0200, Kamil Cholewiński wrote: > Hi Hiltjo, > > On Fri, 06 Oct 2017, Hiltjo Posthuma wrote: > > Where is the patch? > > Attached, example below. However I would rather first discuss what > should be the correct / expected behavior,

Re: [dev] [stest] Hidden file processing

2017-10-07 Thread Kamil Cholewiński
Hi Hiltjo, On Fri, 06 Oct 2017, Hiltjo Posthuma wrote: > Where is the patch? Attached, example below. However I would rather first discuss what should be the correct / expected behavior, before proposing a change. Going fast forward without a clear direction still gets

Re: [dev] [stest] Hidden file processing

2017-10-06 Thread Hiltjo Posthuma
On Fri, Oct 06, 2017 at 03:50:28PM +0200, Kamil Cholewiński wrote: > Hi list, > > stest from dmenu f428f3e produces broken results for paths starting with > a "." that are not hidden files. I think this is best illustrated with a > conversation with the shell: > > > $ ls -d ./bin > > ./bin > > $

[dev] [stest] Hidden file processing

2017-10-06 Thread Kamil Cholewiński
Hi list, stest from dmenu f428f3e produces broken results for paths starting with a "." that are not hidden files. I think this is best illustrated with a conversation with the shell: > $ ls -d ./bin > ./bin > $ stest -d ./bin > $ stest -ad ./bin > ./bin stest should probably treat the path

[dev] [stest] patch: Add option -v for inverted tests

2012-02-29 Thread Martin Kühl
Hi, here is a patch that adds a -v option to stest. The option inverts all other tests, similar to grep -v. Cheers, Martin stest-v.diff Description: Binary data

Re: [dev] stest review

2012-02-11 Thread Anselm R Garbe
On 10 February 2012 01:33, Connor Lane Smith c...@lubutu.com wrote: On 9 February 2012 19:20, Anselm R Garbe garb...@gmail.com wrote: Can we please remove the getopt() dependency? If someone writes an ARGBEGIN-style flag parser with clustering, that's fine. Seems a bit of a waste considering

Re: [dev] stest review

2012-02-11 Thread Anselm R Garbe
On 11 February 2012 01:34, Stephen Paul Weber singpol...@singpolyma.net wrote: Somebody claiming to be Anselm R Garbe wrote: I heavily dislike the fact that dmenu now contains a reference to getopt(). Not exactly dmenu, but stest. Can we please remove the getopt() dependency? What does

Re: [dev] stest review

2012-02-11 Thread Christoph Lohmann
Hello. Anselm R Garbe wrote: However the real point is that the getopt() style or ARGBEGIN crap enables and encourages the developer to introduce a bad command flag interface. Because those approaches hide the utter complexity involved, the developer tends to care less here. This is my main

Re: [dev] stest review

2012-02-11 Thread Christoph Lohmann
Hello. Rob wrote: On Sat, Feb 11, 2012 at 02:04:43PM +0100, Christoph Lohmann wrote: Users will rather be irritated, if the commandline argument hand- ling is different in every application. They then *have* to read the sourcecode for finding out how arguments are handled. What Anselm is

Re: [dev] stest review

2012-02-11 Thread Anselm R Garbe
On 11 February 2012 14:04, Christoph Lohmann 2...@r-36.net wrote: Anselm R Garbe wrote: However the real point is that the getopt() style or ARGBEGIN crap enables and encourages the developer to introduce a bad command flag interface. Because those approaches hide the utter complexity

Re: [dev] stest review

2012-02-11 Thread Kurt H Maier
On Sat, Feb 11, 2012 at 03:39:35PM +0100, Anselm R Garbe wrote: It's quite consistent in most suckless tools actually. One difference I stumbled upon is exactly stest, because it uses the clunky getopt() approach and I really wonder why it needs so many flags. sbase uses getopt and I suspect

Re: [dev] stest review

2012-02-11 Thread Anselm R Garbe
On 11 February 2012 16:02, Kurt H Maier khm-suckl...@intma.in wrote: On Sat, Feb 11, 2012 at 03:39:35PM +0100, Anselm R Garbe wrote: It's quite consistent in most suckless tools actually. One difference I stumbled upon is exactly stest, because it uses the clunky getopt() approach and I really

Re: [dev] stest review

2012-02-10 Thread Bert Münnich
On 10.02.12, Connor Lane Smith wrote: On 9 February 2012 19:20, Anselm R Garbe garb...@gmail.com wrote: Can we please remove the getopt() dependency? If someone writes an ARGBEGIN-style flag parser with clustering, that's fine. Seems a bit of a waste considering getopt is POSIX, but never

Re: [dev] stest review

2012-02-10 Thread Stephen Paul Weber
Somebody claiming to be Anselm R Garbe wrote: I heavily dislike the fact that dmenu now contains a reference to getopt(). Not exactly dmenu, but stest. Can we please remove the getopt() dependency? What does the community have against getopt() ? It certainly beats the pants off of writing

[dev] stest review

2012-02-09 Thread Anselm R Garbe
Hi there, I heavily dislike the fact that dmenu now contains a reference to getopt(). Not exactly dmenu, but stest. Can we please remove the getopt() dependency? Thanks, Anselm

Re: [dev] stest review

2012-02-09 Thread Connor Lane Smith
On 9 February 2012 19:20, Anselm R Garbe garb...@gmail.com wrote: Can we please remove the getopt() dependency? If someone writes an ARGBEGIN-style flag parser with clustering, that's fine. Seems a bit of a waste considering getopt is POSIX, but never mind. cls

[dev] stest

2011-11-23 Thread Connor Lane Smith
Hey all, I've written a tool called stest (stream test), which given a list of files on stdin can filter them by their properties, so ls | stest -fwx yields all writeable and executable regular files in the current directory. I find it really useful being able to do mass tests quickly, sort of