Recent Changes - Search:
Cookbook /

WikiSh-Talk

This page is for discussion / feedback / input / questions / angry denunciations regarding the WikiSh recipe.

(Obsolete issues have been removed. )

It seems WikiSh needs to be fixed for PHP 5.5:

/var/log/httpd/CCCCCCCCCCCCCCC-ssl/error_log-20180401:[Tue Mar 27 10:56:03 2018] [error] [client 141.8.142.53] PHP Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /www/vhost/CCCCCCCCCCCCCCCCCCC/htdocs/Farm-2.2.97/cookbook/WikiSh.php on line 4488

-Johan Bengtsson, 2018-04-24

I've been trying to get wikish to work for years and it never seem to do variable replacement. Is this Cookbook still working?

I have a group called Management and am running these commands from the control panel.

This produces a list of pages: 

ls Management.*

This produces no output and no errors: 

for Manager in Management.*
do
echo Manager: ${Manager}
done

This produces no output and no errors: 

ls Management.* | while read Manager
do
  echo Manager: ${Manager}
done

Any ideas on how to get this working would be greatly appreciated even if it means patching the code if it involves the version of PHP.

pmwiki-2.2.62
PHP 5.3.10-1ubuntu3.8
also failed on fedora 17-19
DannyB Apr 10, 2014

Sorry to hear you've been having so much trouble! I'm running PHP 5.4 (not 5.3, but I think being more updated would indicate that any new requirements from 5.3 would also be present in 5.4) and it seems to be working fine... :-(

Try some of your stuff on http://pmwiki.qdk.org/pmwiki.php?n=WikiSh.ControlPanel -- I just upgraded it to 2.2.62 and still everything you just tried seems to work fine... You can see in my history the commands I put in to test and they seemed to work fine.

The fact that you aren't getting any output at all seems to indicate some systemic difficulty rather than a problem with variable substitution -- something is stopping your loops from looping. Try bypassing the control panel by typing into a page directly as a markup expression:

{(for Manager in Management.*; do; echo Manager: ${Manager}; done)}

And see if you have any better luck that way. If not, can you point me to your control panel to play around a bit, or is it behind a firewall or etc.?

Peter Bowers April 10, 2014, at 05:49 PM

Thanks for looking into this for me. Sorry I cannot let you at our system as it is behind a firewall. Your right about a deeper problem on our end! I tried my scripts on your server and they work. When I try commands directly on a page this is what I get:

{(for Manager in Management.*; do; echo Manager: ${Manager}; done;echo ${PMWIKI_VERSION})}

gives

(for Manager in Management.*; do; echo Manager: ; done;echo pmwiki-2.2.62)

If I put "wikish" after the "(" then I get nothing. It looks like I need to dig through my cookbook items and config.php to see if there is something that is messing things up. Does that sound like the place to start looking?

DannyB Apr 10, 2014

Sorry - yes, you needed that "wikish" in there; I forgot. It appears that something is messed up in your configuration of wikish. If you wanted to send me the relevant portions of your config.php I'd be happy to look at them and see if anything jumps out at me. Just look up my email address (for "Peter Bowers") on the pmwiki-users mailing list -- I sent something just the other day. Peter Bowers April 24, 2014, at 04:40 AM

Is there a way to use the control panel to do a search and replace where the pattern spans more than one line? I'd like to join two lines by removing the newline from the first line: sed -vi 's/WishTheNextLineWereHereToo\n/NowItIs /g' - RandyB June 18, 2010, at 01:06 PM

Not in the straightforward way you've suggested, I'm afraid. The real sed command in bash has this type of capability, but I never even considered a full implementation of sed -- just way too big, I'm afraid.

To accomplish this in wikish you could do something like this: 

echo "start line def\nabc\nsome line ending with def\nghi\nstart def\nend\nline with def" >Temp.Foo
echo "TEST DATA LOOKS LIKE THIS:"
cat Temp.Foo
if grep -q "def$" Temp.Foo
then
   set found = 0
   if test -f Temp.Bar
   then
      rm Temp.Bar
   fi
   cat Temp.Foo | while read ln
   do
      if test ${found} == 1
      then
         echo "${lastln}${ln}" >>Temp.Bar
         set found = 0
      else
         if test ${ln} ~= /def$/
         then
            set -s lastln = "`sed 's/def$//' - '${ln}'`"
            set found = 1
         else
            echo "${ln}" >>Temp.Bar
         fi
      fi
   done
fi
# Handle special case where pattern was on last line
if test ${found} == 1
then
   echo "${lastln}" >>Temp.Bar
fi
echo "CONTENTS OF Temp.Bar:"
cat Temp.Bar

If you were pretty sure it would only occur once in the given text then a line-number-oriented solution could work as well... 

echo "abc\nstart of line def\nghi" >Temp.Foo #Create our test file
grep -n 'def$' Temp.Foo | read --IFS:": " lineno junk
set preline = ${lineno}-1
set postline = ${lineno}+1
sed -n '1,${preline}p' Temp.Foo >Temp.Out
set -s line = "`sed -n -e '${lineno},${lineno}p' -e 's/def$//' Temp.Foo`"
set -s post = "`sed -n '${postline},$p' Temp.Foo`"
echo "${line}${post}"

Of course there should be logic in there to make sure the pattern doesn't occur on the first or last line, etc. It's a bit of a hassle, really... Probably no easy way to do it in wikish. Of course you could define your own markup expression and as long as you made use of the WikiShCompatible() (see MiscMX for examples of how this is used) then you will still have full capabilities of redirecting, taking input from pipes, etc.

Does WikiSh work with a database as pagestore, e.g. SQLite? If so, can it be used to automatically move or convert all the existing flat file Wiki.d pages into the database? RandyB February 07, 2010, at 01:31 AM

No, WikiSh does not know anything about SQLite. It could theoretically be another prefix (like TEXTFILE--, SESSION--, etc.) in the future, but I do not foresee that happening for a significant amount of time, if ever. Glancing through SQLite it appears that Petko has put together an experimental script to import all pages into the DB. However, the referenced page (MergeWikiLibDirs) no longer exists. I would suggest asking Petko since he's already done the development work on it... Meanwhile I've put some stub ideas there that may be helpful to you... (See MergeWikiLibDirs for the rest of the discussion.)

I just noticed that {(substr {$?httpvariable} 1 99)} doesn't execute correctly when I include WikiSh.php. Is that normal, or am I configured wrong? -- RandyB

I'm not sure as I have never used the httpvariables recipe. Can you describe what happens? (Note that {$?getvar} can be done via wikish as ${!getvar} -- actually this gets it from $_REQUEST rather than $_GET but will probably work. Obviously it doesn't solve the problem since it appears there is a "not-playing-nice" between httpvariables and wikish, but at least it gives you a potential workaround in the in-between...). Anyway, if you can give me the specifics as to what to look for I will try to get around to installing httpvariables and exploring inter-operational bugs... --Peter Bowers November 21, 2009, at 07:00 AM

Followup: I've now installed httpvariables and tried it out. The problem has to do with the order of rules. Both '{(' (markup expressions) and '{$?|!@~var}' (httpvariables variable substitution rule) are both defined order-wise as '>{$var}' which means the order is undefined between the 2. '{$?|!@~var}' (identical name which means it gets over-written) also has a '<{$var}' definition (note the < as compared to the >). However, since the identical names cause an over-write of the rule the earlier-defined one is simply ignored. The only way WikiSh is involved in this problem is that it defines rules in the area of {$var} and so the undefined nature of multiple rules with the same order-by argument comes into play and httpvariables then comes after {( instead of before it. All the solutions I can come up with occur within httpvariables.php:

  1. change the name of the rule in the earlier definition of '{$?|!@~var}' to something like '{$?|!@~var}1' so that it won't be over-written (I think this is what was intended and the over-write is simply a bug -- actually I think I remember seeing this discussed, reported, and fixed in httpvariables during traffic on the list, but maybe I'm remembering wrong.)
  2. change the order of the 2nd one to be '<{(' which will guarantee that it fires previous to markup expressions. I don't know what functional specs this might challenge (although since the order was undefined within the rules with the '<{$var}' order argument I don't think anything would have depended on that behavior.)

I'll leave it up to you to report this to httpvariables author if you wish. If you see that I'm missing something and WikiSh is somehow culpable in this I'm willing to take a look at it again... As it stands I think WikiSh is "causing" the problem by doing totally "legal" things which change undefined behavior in rule ordering and so from a practical perspective is "innocent"... Prosecutor, your witness... :-)

[later] Ah, I found the previous discussion for this same issue. You can see Martin's answer where he suggests my #2 suggestion as a change to httpvariables.php -- apparently this never made it into an official release of httpvariables...

http://www.pmichaud.com/pipermail/pmwiki-users/2008-April/050176.html

Here's where PM explained the undefined nature of the order of the rules:

http://www.pmichaud.com/pipermail/pmwiki-users/2008-April/050177.html

(Although he says the 1st over-rides the 2nd it appears to be the other way around in this particular context.)

When I include SecLayer.php before I set $EnableRelativePageVars = 1; PmWiki's expected evaluation changes - as if $EnableRelativePageVars were still set to 0. By setting the variable before the inclusion I seem to have fixed the problem. If the $EnableRelativePageVars needs to be set before SecLayer.php is included, then that should be documented. Was my fix sufficient? Also, are there any other undocumented order of inclusion issues that I need to know about? -- RandyB

SecLayer.php includes stdconfig.php for various technical reasons. For this reason SecLayer should be included late in the configuration. I will update the documentation now. Thanks for letting me know. --Peter Bowers November 20, 2009, at 01:52 AM

Is WikiSh going to be capable of providing a unit-testing framework for PmWiki, for test-driven development? If so, that would be awesome! As you probably know, wikis began at Ward Cunningham's website in the 1990s as a way for programmers to share knowledge about programming patterns especially extreme programming and test driven development. Ironically, recipes to extend PmWiki are not easily tested. As a result, it's hard to make interesting recipes for PmWiki that satisfy the quality standards of major companies. I think PmWiki would get wider use and broader exposure (which would feed on itself) if automated unit testing were easier.

WikiSh is primarily focused on manipulating/comparing page *source*. My understanding of unit testing is that it would need to be manipulating/comparing the final html. I use wikish to unit-test itself, but I'm not sure how broadly useful it would be to unit testing other recipes. (You could use WikiSh for populating pages with data, etc.) I'd be interested in tho'ts showing how it could be done... Or maybe just examples of desirable unit testing -- maybe I'm stuck in a rut in my thinking and not seeing it...

Note that the comment "(in search of some testers to move to beta - it's solid in my scenarios but needs some whitehats))" in the recipe summary causes WikiSh to show up as a false hit on Cookbook.Searching. It would be nice if you could fix that - I'd do it myself, but as the recipe page announces that it gets overwritten regularly that fix could only be temporary. Thanks in advance! :-) --Henning August 19, 2009, at 10:43 AM; Then again, it also is categorized "Searching" so maybe it can be considered a true hit. The request for beta testers still appears out of place in the summary in my opinion. --Henning August 19, 2009, at 10:50 AM

Yes, it is a very useful search tool - that's why it is in the Searching category. I've gotten rid of the "searching for ..." comment so it looks a little nicer on the Searching page -- upgraded to "Beta" at the same time since it's been a long time since I ran into any problems with WikiSh. --Peter Bowers August 19, 2009, at 11:01 AM

Talk page for the WikiSh recipe (users).