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:
> -d Test that f
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, before proposing a change.
>
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 you nowhere.
> $ ./stest
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
> > $
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 with
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
On 11 February 2012 16:02, Kurt H Maier 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 wonder why it
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
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
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 Ans
On Sat, Feb 11, 2012 at 02:04:43PM +0100, Christoph Lohmann wrote:
> Hello.
>
> Anselm R Garbe wrote:
> > If you can write a simple for() loop to process your command line
> > flags, your interface can't be that hard to grasp for the user.
> > Otherwise he will look up the weirdo flags quite often
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 mai
On 11 February 2012 01:34, Stephen Paul Weber 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 the community
On 10 February 2012 01:33, Connor Lane Smith wrote:
> On 9 February 2012 19:20, Anselm R Garbe 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
> neve
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 yo
On 10.02.12, Connor Lane Smith wrote:
> On 9 February 2012 19:20, Anselm R Garbe 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.
Ther
On 9 February 2012 19:20, Anselm R Garbe 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
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
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
19 matches
Mail list logo
