Re: Why is BRE still around? (Re: Porting shell scripts from Tiny Tools)
hello,
On Fri, Nov 17, 2023 at 07:22:57PM +0100, Christian Weisgerber wrote:
> > I the same mood: I realized recently that no implementation of awk
> > seems to implement quantifiers which is really desapointing.
> Awk uses EREs, so if by quantifiers you mean {n,m}, then awk most
> certainly supports this.
I just double checked. works on OBSD as well as the other versions of
awk that are available on my debian.
does() if $awk '/ba{3}b|ba\{3\}b/' | grep -qF baaab
then >&2 echo "$awk does"
else >&2 echo "$awk don't"
fi <<-%
baaab
baab
%
for awk in gawk mawk "busybox awk"; do does
done
which leads me to
gawkdoes
mawkdon't
busybox awk does
Sorry about the fake news :/
Regards,
Marc
Re: Why is BRE still around? (Re: Porting shell scripts from Tiny Tools)
hello, > but note that BREs are not a strict subset of EREs I have to admit that's the way I saw BRE so thanks a lot for noticing me. I the same mood: I realized recently that no implementation of awk seems to implement quantifiers which is really desapointing. I don't realize those things that much because in many cases, perl (with flags like -p, -n, -F, -s, -0 ) let me provide shorter and cleaner solutions than the grep|sed|awk equivalent. > The GNU project turned BREs and EREs into one and the same feature > set in their implementation, just with different syntaxes, causing > a great deal of confusion. It would be nice to compare all those langages. I just googled and found this: https://gist.github.com/CMCDragonkai/6c933f4a7d713ef712145c5eb94a1816 Regards and thanks again for enlightening me today. Marc
Why is BRE still around? (Re: Porting shell scripts from Tiny Tools)
hello, > these tools by default use basic regexps (BRE). Out of curiosity: To me, it's just a reason of retrocompat: no people dare breaking everything at some point. I really dislike the fact that it's confusing (for example: + must be protected but not *). But is there another good reason for BRE to be still alive? (perfomance, simplicity, or anything else). Regards. Marc
Re: vi: count occurrences of a substring
> Otherwise, if I try to just type > :!sed s/abc/abc\/g % | grep -c abc > and press enter, I only get the same output I also get out of same here! I so much wish it worked! regards marc
(technology sucks anyway) Re: vi: count occurrences of a word
hello, > That's a neat trick -- IFF you can be *sure* that character won't show > up in the text. I also feel it's a workaround this is ok as you can easily check if if the caracter won't show. this is a "good enough" principle: don't try to fix *all* the cases, just fix yours. > understand *why* substituting/inserting newlines is something that > seemingly cannot be made to work in OpenBSD sed, or whether the > information on the sed(1) man page is really consistent with actual > behaviour. I'm really happy that sed, awk and all those commands didn't grown to the point they are as heavy as dynamic langages interpreters but if you want do get the job done, perl (and raku if you install it) are there to cover you: :w !perl -0 -nE'say 0+(@a=/abc/g)' :w !raku -e 'say +words.grep(/abc/)' if you need exactly the word abc: :w !raku -e 'say +words.grep()' > Observed oddities: wow ... if you go down that path, you're not finished. Unix has a very long and complex history of experiments, backward compatibilities, standards and habits. long time ago i had a project to make shell programming easier by patching all the tools so they have the same defaut behavior (for example \t as default separator): * this is a lot of work * i didn't bet on a large adoption so unix sucks as all old technologies. * if you want something conceptualy less broken, give plan9 a try * if you want something more polished, give vim+coreutils a try * if you want something convivialist, obenbsd is the best trade off i seen (you can also give try to sbase or 9base) * if you want something more consistent, let's start our project :) * if you want something perfect, let it go :) > Is anyone able to make sense of this? Does anyone know if there's a > reason or rationale behind the BSD sed implementation when it comes to > newlines? life is made of trades off :) sorry. regards, marc
Re: vi: count occurrences of a word
hello, > :!sed s/abc/abc\n/g % | grep -c abc Note: in sed, "what i just matched" is noted & > Googled information suggests that the opposite of what's described in > the man page may be true: You CAN use a literal newline, but you > can't use \n. BSD sed is more litteral AFAIK so you need to escape a real 0x10 but both GNU and BSD support escaped newlines: sed 's/abc/&\ /g' This doesn't help in vi so you can fake it for a moment using tr: sed 's/abc/&œ/g' | tr œ '\n' Another solution is to write commands for this kind of tasks: <<\. cat > ~/x #! /bin/ksh sed -r 's/a/&\ /g' . then from vi, :w !~/x > literal carriage return, not a literal newline (^J). That's the case > on Linux as well, and I don't know why. neither do i. > Your new subject line is slightly imprecise, as words are usually > whitespace-delimited, and I was "looking for a way to count > occurrences of > 'abc' in FILE". Not every substring is a word. right ... wasn't thinking that much to the name. sorry :) regards marc
Re: vi: count occurrences of a word
hello,
> > so you can write:
> >
> > :w|grep -c abc %
> That doesn't really fit the bill:
> 1. This error message is produced: 'The grep command is unknown'
because i wasted it by missing the bang
:w|!grep -c abc %
is a single line way to write
:w
:!grep -c abc %
> 2. grep only counts the number of lines. If the 'abc' reappears in
> the same line, grep won't catch that. My version will, however
> crufty, though it's arguably better/shorter/more portable to use your
> %:
true. is this fine enough ?
:w !tr -cs '[:alnum:]' '\n'|grep -c abc
> > :w !grep -c
>
> That produces a grep usage prompt here, along with this message:
> 'grep -c: exited with status 2.'
... was an example: you can add your pattern there
:w !grep -c abc
> Are you sure you've tested this and that you're using just plain (n)vi?
nvi debian and vi from openbsd 6.9
> Wow, that's... helpful(?), I think, but truth be told
oh yes it is :)
> I've tested
> none of this, because I'm slightly overwhelmed by what to me looks
> like far greater complexity than :E, ^W etc. -- and even than my
> occurrence-counting one-liner.
Fair enough. so check the quick ref about windows (:h Q_wi) especially
the ones that makes you feel the nvi way.
CTRL-W s or :splitsplit window into two parts
:split {file} split window and edit {file} in one of them
CTRL-W ]split window and jump to tag under cursor
CTRL-W fsplit window and edit file name under the cursor
CTRL-W ^split window and edit alternate file
CTRL-W jmove cursor to window below
CTRL-W kmove cursor to window above
CTRL-W CTRL-W move cursor to window below (wrap)
CTRL-W Wmove cursor to window above (wrap)
CTRL-W tmove cursor to top window
CTRL-W bmove cursor to bottom window
CTRL-W pmove cursor to previous active window
> Maybe I'm just not truly ready for vim (though I do use it at times).
there is no such thing as 'ready for vim'. nowadays, i still find stuff
on the vim help and think 'damn! i missed it since 25 years!' vi (and
vim) is a langage the way english is: lot of experience and vocabulary
helps you to be much more concise and precise but you don't need PhD
to have helpful cheap chats.
> None of the above is intended as throwing anything back in your face
> however, and I thank you very much for your reply.
I really don't took things personally and i know that vim is an
overbloated vi but some features are really awesome and the UI is
simpler to use (i don't care about the look but vim is more forgiven
and comes with helpful visual signals). On the other hand: nvi is a too
minimal subset of it to be my daily editor but it's really helpful for
simple sysop tasks.
>From time to time, someone starts a new clone to try to reach a new
balance but vim and nvi pleases enough people so those projects are doomed.
regards,
marc
vi: count occurrences of a word
> 'abc' in FILE, from within vi.
* % means 'the current file' in vi commands so you can write
* | is the command separator
* grep has a -c flag to count occurrences
so you can write:
:w|grep -c abc %
you can also write the content of the buffer to a pipe (my prefered
solution here):
:w !grep -c
> Sadly, :E doesn't actually work in vim. It says
> > E464: Ambiguous use of user-defined command
> I don't know what works in vim. vim prolly has a dozen
> chrome-electroplated ways to do the same thing, but I don't know them.
:h windows
also:
:h :new
:h :enew
:h gf
:h :bu
:h :ls
:h :bw
the following code isfrom my ~/.vimrc so i can:
* navigate into buffers with and arrows
* come back to the first buffer with
* have a fzf menu of the current buffers using
set hidden
command! -nargs=0 BU redir! > ~/.v.json | silent echo json_encode(getbufinfo())
| redir END
\| silent exec "!vim_BU ~/.v.json ~/.v"
\|so ~/.v
\|redraw!
nnoremap :BU
nnoremap :bfirst!
nnoremap :bnext!
nnoremap :bprevious!
the code of vim_BU (i can probably get grid of perl and use jq instead):
vim_BU () {
perl -MEnv -MJSON -w0 -nE'
map +( printf "%3s %s%s %s\n"
, $$_{bufnr}
, ( $$_{hidden} ? "h" : "a" )
, ( $$_{changed} ? "+" : " " )
, ( length $$_{name} ? $$_{name} : "NONAME" )
), @{ decode_json $_ }
' $1 | fzf | awk '{print "bu "$1}' > $2
}
regards
marc
Re: vi golf: command on a motion?
hello, > The bang command has an equivalent in vi. this is the same command indeed but the ergonomy is quite different: vi don't "generate" the begining of a command including the range so we can't just delete a char and edit. > The closest you > can get to executing the same replacement via a vi command is using the > & command which operates on one line. i forgotten & (not that useful in vim) but yes! now you reminds me, it makes perfect sense to use it in nvi. thanks. marc
vi golf: command on a motion?
hello people, Does anyone know how to get this done even faster: ma } :'a,ms/foo/bar even if it's short, I really would like to have something which work the way I abuse the ! command in vim: !} actually write a range on command line like :.,.6! so I just have to replace the ! by s/foo/bar and i get the job done. anything i missed in the doc to be that concise with vi? regards. marc
Re: support new
hello Ottavio, > BTW, for the non-initiated, what is this? https://www.openbsd.org/groups.html see the "this template" link to go there: https://www.openbsd.org/grp-tmpl.txt cheers, marc
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo,
> Heck, piping to sort, or wc + undo are two of the most common used
> commands.
no need to pipe and undo: just write to a pipe
:%w !wc
> Under vi, !}fmt is also a favorite
> though vim does have better integrated commands...
AFAIK, ! work exactly the same between vim and vi. even !!
to recall the last filter works so
!!!^M
apply the last used filter on the current line. vim makes !
even more enjoyable because it combines with extra features
in a so convenient way. an example is gF:
let's say you're reading a mail in where the sender refers to
this function_with_a_very_long_name() you never read of
before ... and you want to see some code.
in vi you can
:cd ~/src/myproject
:!ctags -R
:tag function_with_a_very_long_name
the most borring part were to write the :tag line (or you
had to use the mouse).
in vim, you will edit the command line (:h q:) in a buffer
and use completion (:h i_CTRL-N)
q:tag fun^N
cool ... but now you want navigate through the calls of this
function? use gF (:h gF):
# means "carriage return" in the vim macro notation
# is for CTRL+x
:new # or n to split
q:r !grep -RFwn fun
now you have a new buffer with lines like
main.c:45:function_with_a_very_long_name("/etc/hostname",3);
put your cursor in on the filename, type gF (or if you want to
split) and here you are: in file main.c line 45.
the use and abuse of the quickfix (:make, :set aw, ...) boosted my
productivity too. piping and forking aside: i already mentionned the
text objects (:h text-objects) in another thread but once you have this,
you can't consider vi as a decent replacement of vim. no matter how
bloated vim is. it an editor with a better balance between simplicity
and functionality existed, i'll use it for sure.
marc
PS: i'll run a workshop on vim/vi during the next slcon (not announced
yet) so it will be a good opportunity to make this thread goes on.
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo, > > rare cases. so i finally think it's not worth ... col -b is an elegant > > solution. > Premature optimization is evil. this case isn't about optimizing, it's about slowing down 99.999% to add a case that already have an elegant and simple solution. but as i said: i don't feel skilled enough to be sure of anything. your call ;) cheers marc
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo, > :map K yw:E /tmp/vi.keyword.$$p!!xargs man > > i get: > > Error detected while processing function > line 30: > E132: Function call depth is higher than 'maxfuncdepth' > Press ENTER or type command to continue it's a bug in the :E command, i reported it there: https://github.com/vim/vim/issues/5723 thank you for spotting it. > Also, the patch that would be required is very small and straightforward. indeed. you made me like reading C code. > So, what do people think? Should i test the patch below in more > depth and commit it? Or do people consider this bloat? i'm very naive about performance things but: as you add a condition in a loop that is used while reading the input, it will be a little bit slower. which means penality for everyone to avoid using a very simple pipe on rare cases. so i finally think it's not worth ... col -b is an elegant solution. regards marc
Re: man to render pure text? (or a pipe in vi macros ?)
> I have no idea what the "much more" refers to. all the things i can do with vim are very useful while reading a man page. * a file is mentionned ? use gf to jump in it * a command is provided? edit it so it fit your system and run it with !! * want to add something to your notes? ranges to the rescue: .,'aw >> ~/notes * and so on ... actually the more i know vim, the less i use the shell because i never had to copy/paste anymore. an example: to understand the tagging functionality, i wanted to read the man page from my clone of the openbsd repo. i have a command L defined like this: command -range L ,!xargs locate so i typed this on a line *openbsd*less.1 then i use command :L to get /home/mc/src/vendor/openbsd/usr.bin/less/less.1 so i typed !!xargs man and i get the content. this is the kind of shortcuts i use all the time. > The main effect is to lose tagging functionality. > default pager, you cannot use the :t functionality to move to the > place where a word is defined. vim has a very good support of file navigation using ctags. however i don't know what to ctag on and what should be the usage from man. is this the ability to navigate into the manpages? > Yikes. I had no idea what either of these are doing and had to > try them out. vi(1) contains so much bloat that is never really > needed and doesn't belong in a text editor at all. i really consider vim as a multipurpose interactive tui, not an editor. i understand your concern about bloated softwares but i come from a world where colleagues are editing java and python code using ms code (editor based on an html render) to create web applications. so vim is not that bloated. also: reading/writing from/to pipes/buffer gave me a lot of power and spare me the time to find, test and learn new tools to achieve the same. i have only one multipurpose tui i learned and tuned since the last millenium that helps me to edit mails (with spelling), code (with quickfix mode and so on) and some macros i wrote 20 years ago still serves me today. > > feature in openbsd vi. the linux version > > > > map K yw:E /tmp/vi.keyword.$$p!!xargs man > > You don't say what that is supposed to do. sorry. map K yw:E /tmp/vi.keyword.$$p!!xargs man should be read: map K # whenever i press K in normal mode yw# yank the word :E /tmp/vi.keyword.$$ # edit /tmp/vi.keyword.$$ in a new window p # put the word you just pasted in the buffer !!xargs man # filter the current line with xargs man as a result: if the cursor is on the r of the word rctrl and i press K, the manual appears in a new window > Under Debian Jessie, if i start "vim", then type > :map K yw:E /tmp/vi.keyword.$$p!!xargs man > als > K > E132: Function call depth is higher than 'maxfuncdepth' > Press ENTER or type command to continue you can call a map from a map and it seems something like this happens in your case. vim mappings can avoid recursions: use noremap instead of map. however: K is built-in in vim and is much more powerful than my poor macro: * it relies on the 'isk' variable so you can set which chars can be a part of a command * it relies on 'kp' so you can choose an alternative to man to open the doc (perldoc is useful when editing perl code) * the cursor don't need to be on the very first char of the command: anywhere on the command is fine. > I also tried the same with OpenBSD vi(1) and it resulted in > > Usage: e[dit][!] [+cmd] [file]. > > So, no idea what you are trying to do. you have to be on the first letter of the command so instead of als K try als b K > In 2014, i already wrote a patch to do that because the question > came up repeatedly. But demand wasn't that high after all, so i > never committed it. Now, i updated the patch to -current, see > below. i'll try to read this code as soon as possible. > On the one hand, the UNIX phlosophy is to have each tool do one > thing well, then use pipes to connect tools as needed. > arguably, you maybe shouldn't need another tool to just revert > something that the first tool does. > Why would *not* adding backspace > formatting require a pipe to another program, rather than not adding > it in the first place? can't reply on that: out of my skillset :) anyway: thank you very much for taking time help me. regards marc
Re: man to render pure text? (or a pipe in vi macros ?)
dear Ingo, > Absolutely. Using web searches for software documentation is an > awkward and error-prone crutch that should be avoided for many > reasons. For OpenBSD documentation, it is never needed. Actually, the quality of the manpages was one of the reasons i tried openbsd and one of the reasons i emphasize when i try to sell openbsd. > If careful scrutiny of an OpenBSD manual page leaves the impression > that information may be missing from the page, asking on misc@ is > a good idea and often results in an improvement of the manual page. reading both man pages and answers on mailing list makes me aware of other options, features, alternative ways to do things and think about the problems. this is so much enjoyable than copy pasting from a top rated stackoverflow answer. > Only for low-quality software, searching the web may occasionally > be needed. so true. thanks marc
Re: man to render pure text? (or a pipe in vi macros ?)
hello, On Mon, Mar 02, 2020 at 12:06:42PM -0500, Raul Miller wrote: > Have you looked at: > man col > ? how can you come to the point to read the manpage of a command that doesn't seems to be related to your problem (i was searching something around the man input so i tried troff, mandoc, man, ...). Reading from David, i thought col was mentionned in the man manpage. I just read from a recent source of man.1 and realized my openbsd is just too old. at the line 352: .Dl $ man -T ascii -O width=65 pledge | col -b > And, for that matter, have you looked at >man col | cat -vet | less well ... my idea was to remove noise. not add more. > Alternatively, have you tried using any web searches on this topic? i have to admit i try to avoid the web for many reasons so i try to stick to manpages, FAQ, mailing list archives. for the openbsd one, i use https://marc.info/?l=openbsd-misc thanks for helping. marc
Re: man to render pure text? (or a pipe in vi macros ?)
hello, > Try the mandoc manual page, man is just a front-end to it. Both > man/mandoc support -T option and you can specify ascii/utf8 to get the > formatted page but it still adds all escape sequences. indeed, that's why i asked > The documentation > says to pipe the output to col -b to suppress them (I think what you did > with the alternative fmt command). i felt dumb reading this as i gave a try to the mandoc man. but i just double checked: man mandoc|col -b|grep -w col gives me nothing. can you please tell me what documentation explicitly refers to col -b? i can probably learn more from it. regards marc
Re: man to render pure text? (or a pipe in vi macros ?)
> It's the designated tool for the job. That fmt also happens to > replace sequences character1-backspace-character2 with character2 > is more of a lucky coincidence. ok then ... good to know. so by extension: by design, there is no way to use the man command to render the text directly? regards, marc
Re: man to render pure text? (or a pipe in vi macros ?)
hello, > > * is there a way to ask man to deliver pure (non-formatted) text ? > Pipe its output through "col -b". what is the gain of using col over fmt ? > > * is there a way to introduce a | in vi macros? > Yes, by prefixing it with a ^V character. To enter ^V in vi's input > mode, press control-V twice. grmbl ... how could i have missed this one ... thank you! regards marc
man to render pure text? (or a pipe in vi macros ?)
hello, coming from linux, i'm used to read manpages in a vi buffer so i can do much more than reading the content. i basically use :r !man ls or !!sh (when the line content is "man ls") under openbsd, it seems man doesn't if stdout is a tty. i digged the man manual a little bit without finding a solution so i worked the things around: :r !man ls|fmt now i would like a poor version of keyword feature in openbsd vi. the linux version map K yw:E /tmp/vi.keyword.$$p!!xargs man becomes map K yw:E /tmp/vi.keyword.$$p!!xargs -IX sh -c 'man X|fmt' which doesn't work as | separates 2 vi commands. i really would like to know one or the two of these: * is there a way to ask man to deliver pure (non-formatted) text ? * is there a way to introduce a | in vi macros? regards marc
Re: FreeBSD daemon(8)-like command for OpenBSD
hello, > PID=`pgrep gloob` > if [ -z "$PID" ] > then > /usr/local/bin/gloob -f poor_security_a_bad_idea_to_run.conf > fi is there a reason to not use the pgrep status ? pgrep -q gloob || /usr/local/bin/gloob regards, marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> you can do by array Both of them are borring once you used the signatures but they are still experimental. Also: if you don't mind a new dependency: Function::Paramaters is so much convenient. regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> Any modern mailreader can easily tag messages as thread, so it's trivial to > avoid a given thread, as long as people don't fuck around with the > In-Reply-To info. i have to admit this isn't an argument: if most of the people don't read it, we should have the ability to save bandwidth by setting up a temp list or adding a + alias. i add this in my todolist. regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> Yes well, my point is if you want to make a piece of code
> incomprehensible, I don't think there is a language that will stop you.
indeed. but i now realize the counterpart is not true because everyone
has something different in mind when it comes to readability.
last example was yesterday: i wrote this in raku:
my %final_pairs = @*ARGFILES.words.hash
i asked for code review for the python counterpart and we got:
import sys
def words():
for s in sys.argv[1:]:
with open(s) as fh:
for l in fh.readlines():
for w in l.split(): yield(w)
w = words()
final_pairs = { k : v for k,v in zip(w,w) }
i don't need the perl version but it would something like:
my %final_pairs =
grep length,
map { split /\S+/ }
map { chomp; $_ }
<>;
for me, readability score is: raku, perl, python but someone gives
arguments:
* there is no reason a list could be considered as a hash by order
of appearance
* there is nothing more unreadable than implicity (split on what?
what is $_?, <> iters on what?)
i strongly disagree but this is a valid opinion. i know that many
people struggle with side effects for example so $x++ is convenience for
the one of us that are used to iteration but it's hell for lot of
newcommers.
> It's a choice of the writer to write code that's hard to understand.
> Perl is a very expressive language, and can be used to write very clean
> and maintainable code.
that's it. and some of us hate expressivity because it means: learn how
the langage behave when it's preferable to describe the same patterns
again and again ...
> I think the "there's no right way" mantra helps: it allows you the
> latitude to choose the style that makes the most sense for the problem
> being solved.
yes ... but "it could be a default way because experience shown its
convenience or ability to solve the most common problem" (which is what
perl and raku do, i guess), is something that can be loved or hated.
regards
marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> You have something like 3 lines of perl to play with ;) is there a todo list somewhere ? regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
On Thu, Jan 02, 2020 at 02:16:52PM -0500, Daniel Jakots wrote: > On Thu, 2 Jan 2020 19:49:28 +0100, Marc Chantreux > > some endless sterile debates > Like this thread, or worse? * long doesn't mean endless * sharing points of view is never sterile (yours is inspired by other ones, right?) so i think this thread is neither sterile nor endless but maybe it's not the good channel: please let us know if there is a better place than misc@ for that. regards. marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
On Thu, Jan 02, 2020 at 10:42:54AM -0600, danieljb...@icloud.com wrote: > I don't understand why people say that perl's flexibility is a negative. because sometimes, flexibility permit some endless sterile debates about the coding style. marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> I will always lean towards idiot-proofing the code. :)) fair enough. regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
hello,
> > my %user = qw(
> > login mc
> > shell /bin/zsh
> > );
> > print $user{login};
> my %user = ( login => 'mc', shell => 'bin/zsh');
> is way more readable in that case, I think,
> and it does showcase what a *smart* quoting system can do.
well ... i prefer the way i wrote because i love to:
* remove useless symbols
* read columns
but yes: the drawback of perl is: there are so many ways to do
it so every project needs a clear coding style.
regards
marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> Not sure about anyone else, but comparing the Python vs Perl example you
> gave above, I would still say Python is the nicer-looking language.
i was just saying that there is no need for yield in perl. now i can
show you tons of examples to demonstrate perl code is not only
more "unixish" but easier to:
* write
* read
* modularize (__init__.py always made me smile)
when you have to manipulate text files or large datastructures, python
is far behind perl. i won't try to convince you but to illustrate what
is said before. see this code:
use v5.20;
while (<>) {
chomp;
# trim and print lines only when not empty
say s/
^ \s+# triml
| \s+ $ # trimr
//rx if /\S/;
}
this is *hell* for a unix newbie:
* regexps is a concept that windows programmers (so python ones too)
try to avoid (pretending it's hard to understand and read)
* ARGV ... what is a "filter" anyway? i don't want to read about
the unix litterature to write my code.
to be fair: if you just write a web application or a datascience script
were datasources are from binary formats or databases and libraries are
available, you just don't need those tools and run away is probably
the good strategy (python *is* indeed easier to learn when you have
simple things to code). if you believe in text streams and simple formats
in a unix land (which i do), or if you need to solve complex problems,
learn those concepts and be familiar with them is worth it.
another "line noise" bullshit comes from sigils and i have to admit
i though sigils made my script looks "not professional" when i was
younger (having a php background). But when you understand the way
sigils works, it appears that it is very informative and useful:
* they always give clues about the structures you're working with
* they permit some very useful shortcuts
as example: hash slices is something i always miss in python.
use v5.20;
my %user;
my @names = qw( uid gecos home shell );
my @cols = qw( 0 3 56 );
@user{@names} = map
{ chomp; (split /:/)[@cols] }
`getent passwd mc`;
printf '%s is the default shell for %s'
, @user{qw( uid shell )};
sure, python is evolving in the good direction (see PEPs 448, 449, 572 ...)
but so many things are missing to be confortable comparing to perl
(sometimes little ones but so convenient). some examples that comes to
my mind:
the quoting system
# qw( for a list of barewords )
my %user = qw(
login mc
shell /bin/zsh
);
print $user{login};
# q() and qq() to replace '' and "" when it's complicated
my $comment = qq{
with qq() you can choose your delimiter like in sed
so you can't get it wrong or unreadable
even if you have "" in mind
}
yada to spot an unimplemented section
(https://perldoc.perl.org/perlsyn.html#The-Ellipsis-Statement)),
the //g modifier with the \G anchor (so you can iterate in a string with regexp
matching), ...
so many other ones. and python people don't get those are
very useful features. when i asked for fair help, the
anwsers were often flooded in tons of messages like:
* you don't need this
* you shouldn't program with this
* perl is dead
So even the community is anoying and i don't want
this logo++ to be unfairly compared to perl anymore
but as i said: i don't want to reboot a 2 decades sterile
feed:
* since 3.4 python became bearable (so much saner than php or js)
and a good tool for teaching OO.
* both python and perl are langages from the last millenium with
lot of issues that are fixed in raku. so that's the spot i switched to.
cheers
marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
hello Stuart, > Heh, I've heard Perl described as executable line noise, and for sure, > it will let you write code like that. arf ... i just tried to explain were this "linenoise" bullshit came from just in the answer i gave to frank regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
> Did you ever look at the suite of modules from John Syracusa (DB::Rose and > the like) ? fairly clean and nice. I had this under my radar but no one around be wanted to test anything else but DBIxC so i never took time to read the code or use it. regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
hello,
> > what do you mean by this? prototypes are here for decades and signatures
> > are experimental and i guess it will be core in some releases.
> Stuff like
> $o->method { code }
ooohh right! this is a thing i also missed with perl (fixed in raku).
> > Template toolkit is still by far the best template toolkit i know.
> > i really thing the only thing where perl was not a precursor in web dev
> > is plack (which is inspired by wsgi which is inspired by rack ... i
> > don't know if there is another ancestor).
> That's the big issue. Too much choice in the ecosystem, with some of it not
> clearly enough explained... and no simple integration with js libraries for
> ajax at first.
> Yeah, I mean mason. At some point long ago, it was about the only
> game in town for perl.
yes! the eperl competitor. i remember that.
> > ActiveRecord was easier than DBIx::Class for simple situations. that's
> > one of the reasons of the popularity of RoR (also the Ruby syntax).
>
> I still thing DBIx::Class is overkill. The DB::Rose stuff was way simpler
> and I would have preferred for it to win.
Well... i liked the simplicity until i had some cases like having 2
different DBs with the same model: piece of cake with DBIxC and
impossible with ActiveRecord (AFAIR).
regards
marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
hello, > The only thing that's really missing in perl is proper thread support. > Don't know if that's going to happen. just to be sure: are you aware of the MCE module? https://metacpan.org/pod/distribution/MCE/lib/MCE.pod regards marc
Re: Suggestion: Replace Perl with Lua in the OpenBSD Base System
hello, > Actually all the cool and useful ideas that perl6 had DID trickle down > into perl5 a few years ago. even if you load a lot of modules from CPAN (which i tried to do with https://metacpan.org/pod/Sympatic), this is not even close to be true! for example, raku has * PEGs are objects * make multithreaded programming easier than i never seen before * gradually typing, subsetting types are core * has much more powerful metamodel, sub and method signatures * metaoperators * lambda syntax made right * Whatever operator * andless possibilities of new operators that can be used postfixed, infixed, prefixed and more ... * multi signatures (pattern matching for signatures) * multiple backends (currently jvm and moarvm) also: globally the langage is much more concistent and readable than every dynamic langage i saw before. > Perl6 was (I think) intended as a test bed for ideas by Larry. Everybody > got sidelined when a perl6 implementation came out of nowhere, > written by Audrey Tang, an extra-terrestrial years ahead of everyone. AFAIK, pugs (it was the name of this implementation) made it possible to write a test suite that became a reference for all the future implementations of perl6 (now raku). Now there is a complete community around the current defacto official backend (named rakudo). raku is the perl of 2020: a dynamic langage that is ahead of its time made by an inspiring, competent and dedicated community which suck at marketing. regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
hello, > The only thing that's really missing in perl is proper thread support. > Don't know if that's going to happen. seems ... complicated ... > I have a wish-list of things that are not that likely to happen, I would > like to be able to use prototypes on methods, for instance. what do you mean by this? prototypes are here for decades and signatures are experimental and i guess it will be core in some releases. also, thanks to pluggable keywords, some very powerful modules exists like https://metacpan.org/pod/Function::Parameters > Perl also missed a turn for web development. I think Catalyst was a huge > mistake (hey, you've got *choices* everywhere. Let's confuse everyone), perl had CGI.pm, maypole, mod_perl, catalyst, jifty, dancer, mojolicious ... Template toolkit is still by far the best template toolkit i know. i really thing the only thing where perl was not a precursor in web dev is plack (which is inspired by wsgi which is inspired by rack ... i don't know if there is another ancestor). > so a lot of people didn't transition from Meson to another perl module, but > instead switched to ruby-on-rails or something like that. you mean mason ? mason is the php of perl: don't organize your code: write a single page with everything in it ... it was a terrible thing to maintain (see the code of request tracker...). > Dancer was a few years too late to the party. sinatra (from ruby) was the source of inspiration of Dancer which, AFAIK, appears years before flask and bottle. ActiveRecord was easier than DBIx::Class for simple situations. that's one of the reasons of the popularity of RoR (also the Ruby syntax). regards marc
Re: perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
hello,
as intro: i would like to make clear that i'm not promoting perl (my go
to langage for scripting is now raku by far) but as i was a member of the perl
community more than 20 years, i have some opinions about it.
> felt like a random hack, especially compared to ruby. The only thing I
> really miss from python is "yield".
why is this ? return is the perl yield. the only difference is that the
"exhausted" situation is on your own. so basically:
def count_from(x):
while True:
yield x
x = x + 1
naturals = count_from(0)
print(next(naturals))
print(next(naturals))
print(next(naturals))
print(next(naturals))
is written in perl
use experimental 'signatures';
use feature 'say';
sub count_from ($x) { sub { $x++ } }
sub NEXT ($generator) { $generator->() }
my $naturals = count_from 0;
say NEXT $naturals;
say NEXT $naturals;
say NEXT $naturals;
say NEXT $naturals;
there are complete modules on CPAN based on this. Perlude provide
keywords stolen from haskell to make things more like shell scripting
so the equivalent of
grep root "$@" | sed 100q
is
use Perlude;
now {print}
take 100,
filter { /root/ }
sub{ // () };
Perlude is available on CPAN:
https://metacpan.org/pod/distribution/perlude/lib/Perlude.pod
> and ruby in parallel and ruby was definitely the winner there. I have
> absolutely no idea why python even gained the popularity it has, it
my opinion: python gained popularity during the dark ages of internet
when most of the people (including developpers and IT people) were using
windows and teach themselves how to use a computer or worse: learned
from java schools.
so python won because:
* they took care about windows users
* the langage is designed to provide simple solutions for simple cases
which please most of the users (they don't need to maintain large
codebases)
* the default behaviors of the langage were the same than the langages
learned in the java schools (POO, ...). the most obvious example is
the "flatten values by default":
* it became the center of the stupidest talk ever
https://media.ccc.de/v/31c3_-_6243_-_en_-_saal_1_-_201412292200_-_the_perl_jam_exploiting_a_20_year-old_vulnerability_-_netanel_rubin
* thanks to javascript, (with the rest operator and the
destructuring syntax) they now all get the point and even python
dpeople now have access to those features and like this.
https://youtu.be/ggbi4SelOAo?t=955
so perl didn't fit the needs of the internet bubble
* perl were about unix culture, mailing lists and so on: they setup a
confortable cocoon to work together and this cocoon became an echo
chamber when the other communities started to use third party services
like stack overflow.
* something i call "the 'hello world' pride": when perl programmers were
just putting new modules on CPAN to get the job done, python ones were
creating tools and projet sites and so on with a logo "powered by
python". this has an impact on the myth of "perl is dying"
* the python community was unfair comparing the langages (using ugly
perl code and nice python counterparts). instead of taking time to
explain all the biases, perl community repetedly asserted that the
authors of those article were incompetents and gone away.
* same situation regarding the constant FUD from the other dynamic
langages
perl people didn't realised how unixish perl is:
* it's sad to realize that even linux users of nowaday are not
confortable with the basics of awk, sed and so on ... and perl
is born by improving the concepts of those langages and putting
them together in one tool. it means that learning perl is easy for
unix users: not for the rest of us. combined to the "DWIM" moto, perl
has some unexpected behavior because it implies you should *know* what
you should mean (which implies a unix culture). the most obvious
exemple for me is the fact that <> iterates by default on ARGV, not on
STDIN: ARGV is what you need to know when you want to write a filter
but it's way too magic when you don't know the unix philosophy.
* when perl gained popularity (the realm of CGIs), lot of aweful scripts
were written by newbies both in perl and unix. the result was terrible
and gave perl a very bad reputation.
regards
marc
perl popularity inside openbsd community? (Re: Suggestion: Replace Perl ...)
On Tue, Dec 31, 2019 at 06:57:02AM -0600, Daniel Boyd wrote: > As one of the few remaining people out there who considers perl to be > their favorite language—starting to wonder if it’s just me and Larry > Wall at this point—I’d like to say that perl should stay in base on > its merits, all the perl-based system tools notwithstanding. one of the few remaining people ? is it so ? i really wonder ... Perl bashing is around the IT crowd for 20 decades and yet, when i compare with other dynamic langages: * perl is the only one who gives me the conciseness and spirit of unix tools combined to the power of a dynamic langage (the only close one is ruby, the next level is raku, the others look like jokes to me). so as openbsd people seems to be confortable with this unix culture, i'm inclined to think that perl is popular here. * CPAN is the best ecosystem to share code (metacpan is just awesome compared to the other package sites, tooling is very good as well) * the popularity of perl around me don't reflect the "perl is dead" moto we heard since so many years (yes: there is a decline but it's in flavor of compiled langages. the only one who switched to python made this choice for money reason) both perl and openbsd popularities are underestimated just because they still prefer mailing lists over stackoverflow (or other web services who try to buzz with some charts) and don't care that much about marketing. but still: i will be curious to know the perl popularity in the openbsd community. regards. marc
Re: Relayd in docker
> I am running docker(yeah i know ..) but anyhow the task is to get a > nice load balancer up in a docker container and i want to use relayd > ofcourse ! has anyone gotten relayd to work in docker or has anyone > created openbsd images for docker ? AFAIK, docker is just an ugly wrapper on top of cgroups and linux namespaces: there is no way to have a openbsd docker. > If not i guess i have to compile it and run it on a linux docker > image... please report any sucess on it: i'm interested. regards marc
Re: Tools for writers
> With the exception of perlpod(1)/pod2man(1), most programs that good to know as i'm really confortable with pod. > page formatting. scdoc(1) is not an exception; the output code > quality is poor indeed > * stray .P before and after .SH > ... this list is really interesting. maybe it should be shared with the scdoc project. it will not solve the problems but at least those ones can be fixed. > To summarize, there wasn't any need for yet another man(7) > autogenerator, perlpod(1) already existed, and while most man(7) > autogenerators are bad, this one may even be producing below-average > quality. my opinion is more blur: using a tool that works find is important but i'm always happy when i can remove a usage of an interpreted langage (even perl which was by far my prefered one before i started to use raku). > Do not use it. i wasn't even wanting to: this one was mostly a joke to tickle you then it ends up to a really interesting and constructive answer. thanks a lot. marc
Re: Tools for writers
hello, > https://www.openbsd.org/papers/bsdcan18-mandoc.pdf which leds me to the conference video. it was really interesting. > Nothing is wrong with trying to make things simple for users, quite > to the contrary. But that is not an excuse for delivering solutions > that are technically abominable. ok. now i get your honorable point but the lazy part of me will take its part of abomination to get things done in a pleasant way :) also: i didn't dive that much in pandoc code but from what i saw: even a non-fluent haskell person which i am can read this code. > When a language is technically > as ill-designed as markdown is, the multitude of resulting traps > actually makes it very hard to use, *not* easy at all. well ... i really think this is a bias because i really think markdown is so easy to use it popularized the use of wiki syntaxes (which mean less use of wysiwyg tools ... which is more abominable). let me ruin your day: are you aware of scdoc? https://git.sr.ht/~sircmpwn/scdoc i really appreciated reading about you opinion. thank you. regards marc
Re: Tools for writers
> > > documentation language, mdoc(7), at all, neither for input nor for
> > > output, already makes me raise an eyebrow or two
> Vim has many useful HTML plugins (or write your own)
yes ... but why should i bother with an uggly distracting format when
i can have a format that is close visually to the idea i have in mind
(a list). also i made other points that aren't adressed by vim plugins.
> The above list require two keystrokes and a number of list items wanted
> in one plugin I have barely started to use.
yet another plugin to install, maintain and learn when i can rely on
external commands i can use in other contexts;
> A print CSS file can do a tremendous amount of formatting useful for
> printed documents.
what if you want to use music cheets, chemical structures, good looking
math formula or other material. latex comes with tikz, beamer, qtree,
all those things that makes good looking printed documents much easier
to produce ...
html is when i need interactivity or animation but it's always a
painful process to me. but the point of using markdown remains:
* brian
* ken
* doug
is easier to write, read and edit than
\begin{itemize}
\tightlist
\item
brian
\item
ken
\item
doug
\end{itemize}
or
brian
ken
doug
> I detest Libreoffice. I have never yet gotten it to do anything I
> needed.
so do i: i was interested by arguments against markdown.
> But to each their own. Overall, this thread has been very enlightening
> for me. I do need to learn some other methods. TeX and LaTeX keep coming
> up everywhere I look.
i have to admit i started using both html and latex at the same time and
prefered html at the begining. but with time, latex is much more
rewarding when it comes to printed docs.
the only format that made me really unhappy for the moment is troff but
i still hope i'll have fun with it at some point.
regards
marc
Re: Tools for writers
hello, > > that said: i'll really give troff a try again when i will figure out how > > to create templates for the documents i need (as i said in a previous > > message: i have a layout problem) > > First mention of templates in this four dozen message thread. i replied to this thread but as it was another branch, i changed the subject and the "in reply to" is the id of the original author. sorry if it wasn't the expected behavior. https://marc.info/?l=openbsd-misc=157293688812513=2 > What templates? template or macros: i don't know the good way to do it. the idea is to have the layout used in my organization so i can generate some reports using troff to generate pdf. this would be awesome but setting up a page layout is out of my scope and i haven't found a didactic documentation to just dive in the problem. any help would be much welcome. regards, marc
Re: Tools for writers
hello, > > is one of the most useful tools I have ever used. If you are writing > > any sort of documentation then I *highly* recommend checking it out > I strongly oppose that point. There is no need at all to bother > with pandoc when you write documentation. (It may be useful for > other purposes, i have no idea). yes ... what's the point of using another format than postscript directly. also: using an high level language instead of writing everything in assembly is a chance to lose control over what you're writing. live is long enough to waste time ... i would like to suggest 2 reasons to use pandoc (and the markdown format): it will make the edition and the review of the document much more * easier * inclusive (people are able to read markdown format... but latex, html or troff is too much for lot of people) that said: i'll really give troff a try again when i will figure out how to create templates for the documents i need (as i said in a previous message: i have a layout problem) > The worst one > which you must avoid at all cost is DocBook, closely followed > by Markdown and related formats. agree for docbook but can you explain us what's so wrong with keeping simple things simple the way markdown allows us? i personally prefer textile but markdown became kinda defacto wiki syntax standard with lot of variations. i really like to use human readable formats so markdown and yaml became formats i use every day and enjoy it. > So, when talking about documentation, i have never encountered any > problem that even made me look at pandoc, there is no problem with other formats but can't you admit that for many people, something like * denis * brian * doug is easier to write, read and edit than << ? denis brian doug also: * transpiling is always a good thing to catch and avoid errors. for exemple: did you realize that the "brian" item is broken? this will not happen using a markdown as source * the "proper" way to serialize an html/xml that is not intended to be edited isn't the way i write above but this below instead. and frankly i don't want to edit those kind of stuff denisbriandoug > The fact that pandoc appears to not support the most important > documentation language, mdoc(7), at all, neither for input nor for > output, already makes me raise an eyebrow or two please contribute :) also: the support of troff was removed from graphviz many years ago. how sad is it? > did, i still wouldn't see what it could possibly be useful for. you don't have non technical colleagues, don't you ? Sincerely marc
Re: Tools for writers
> My substitute for _pandoc_ is the _org-mode_ of emacs, which is for some > people also good for outlining etc. if i quit using vim some day, it will be for something lightweight so i'll never run emacs, i guess. regards marc
Re: Tools for writers
hello, > Does _pandoc_ work on OpenBSD now? i realized i haven't try on BSD as my desktop remains a linux for the moment. sorry i lost the focus because of this very appealing thread. regards marc
*roff and page layout ? (Re: Tools for writers)
> the "print/texlive" port is how ridiculously large it is. because it comes with the whole distribution. i never tested but https://tectonic-typesetting.github.io/ seems to fix it by downloading stuff on demand. however, another problem with tex is performance. troff is blazing fast. however... > "textproc/groff" port (disclosure: which i maintain). The roff(7) > The "textproc/heirloom-doctools" port is a serious contender for a ... i tried nroff long time ago so i tried to create templates for memos and letters with layouts where: A is company logo and info B is for metainfo about the current letter C is the actual body ┌─┐┌─┐ │A││B│ └─┘└─┘ ┌┐ │ C │ └┘ ┌─┐┌─┐ │A││C│ │B││ │ │ ││ │ │ ││ │ └─┘└─┘ i tried both of those (you can achieve this with latex minipages) but i never made it work so i gave out. did i miss a fine didactic documentation about it ? regards marc ps: i think it was the plan9 troff, > documentation of groff is vastly superior to LaTeX, and LaTeX > documentation is so extremely huge and fragmented that it's > a terrible challenge to find anything you need). well ... i have to admit i tried harder with LaTeX but thanks to CTAN, i reached the point when i know what are the classes and packages i need (mostly article, book, beamer and tikz). there is no CTAN for troff and that's a missing part. > out LaTeX is easier to program than roff(7) because the syntax and > semantics of the low-level roff(7) language are, let's put it > politely, quite unusual and surprising in many details. i love the way you're saying that. is there a document to dive into it ? > groff, and besides, i did implement considerable parts of the roff > language in /usr/src/usr.bin/mandoc/roff.c. nice. thank you for mandoc! regards marc
Re: Tools for writers
> documents, but for my use case, LibreOffice has treated me well. I primarily > use it for simple things like putting together invoices, writing articles, > rendering documents to PDF or postscript, and reading .docx files people > send me. > I'm sure there's a superior way to do all this, there is no such thing as a "superior way", there are way that fit your expectations: i wasn't trying to convince you to use anything else that please you but i really think toolchain that uses latex as core offers much more opportunity than a libreoffice ones and would like to mention it if it can help. regards > I have to collaborate with average people. I've thought about learning latex > and mandoc and all the fancy tools, but I've just never gotten around to it. I wasn't talking about mandoc but pandoc (https://pandoc.org/): you write most of the things just using markdown format and add latex instructions whenever you want. this way, you keep simple things simple but you keep the power of latex under the wood. regards marc
Re: Tools for writers
hello, > You can't go wrong with LibreOffice. I've written thousands of pages over > the years with it. It may be too "heavy" for some, but for me, if I'm doing > something too complex for vi or mousepad, I just fire up LibreOffice. to me there is no such thing that is too complex for the unix documentation toolchain that you can achieve with libreoffice. i feel the other way around: libreoffice is always a bad choice: * when i need a rich good looking document in which you can easily add graphical material of very different nature (music cheets, chemical or math formula, gantt graph, ...), then [your editor of choice] + pandoc + git + latex + tikz + gnuplot + graphviz + m4 is really the best thing i found * if you need interactivity and animation (which isn't my case): the web is there (i personally use pandoc + pug + livescript (to be replaced by elm) + stylus) the only one case where libreoffice is the good choice is if you mind the learning curve but writting a book is a long process, pay the bill at first to be more peaceful later seems to be a good deal to me. regards. marc
about vim objects (Re: Requesting vi tips)
hello,
> I didn't know [how] ! took movement commands. Thanks. I'll have a play
> with that one.
almost related: in addition to the motions, vim has a notion of objects
:h objects
so you can easily filter a complete paragraph with
!ap
fmt -w72
in visual mode, you can select nested objects by adding a selection
{ // the whole code
{ // the object i want to select
{
you are here
}
}
}
you can select the expected object using va{a{
HTH
marc
Re: BACK TO BASICS (wikipedia's unix family tree)
hello, > > The Unix landscape was fragmented long, long before Linux or the three > > modern BSDs even existed. according to https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg it started almost just after unix was born. regards. marc
Re: Desktop full text search
hello, > use Gnome or KDE so I was wondering what do people use for this. Been > looking at the ports and I see Xapian and others. Any advice on a nice > setup? i have the same problem with both code and documentation. i installed dezi (https://metacpan.org/pod/distribution/Dezi/bin/dezi) and modified the cli dezi client. also wrote some lines of viml to ease navigation from my favorite editor. it's not polished at all but i'm really happy about the first iteration. i can post more if you want. regards marc
