VrrtepCLI

Started by Tirea Aean, May 22, 2011, 03:40:58 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Ningey

Quote from: Tirea Aean on September 16, 2011, 01:47:32 PM
I assume that
Quote...$CLIDIR and set a line like "export CLIDIR=<something>"...

would make it so that it installs to whatever directory the terminal is currently in.

This fix seems simple enough, All I'd have to do is add/change a few lines in install.sh, and then update the README.txt file. When I have some time, I'll figure this out and commit.

That would be one possibility, another one (again, not mutually exclusive ;) ) would be to pass a parameter to the installer that specifies the target directory.
This way you would be able to install it either to a user's homedir (that would be how it works right now - with any user) or to a specified dir (which in turn would have to be created if not present) - the latter of which requires superuser privileges but makes it available to any users present on the machine.
The only ramification would be that you would need superuser privileges to update the databases (there should be a way to deal with that one, too).

I'm attempting to find a way to deal with these issues as well - maybe we should sync on that later on to find a solution.

Kìyevame!

Ningey


"Sawtute ke tsun nivume - fo ke kerame!"
-- Neytiri te Tskaha Mo'at'ite

"There are two things that are infinite: Human stupidity and the universe. However, I'm not yet sure about the universe."
-- Albert Einstein

"He who gives up freedom for security deserves neither and loses both."
-- Benjamin Franklin

Swoka Ikran

Just updated Windows version. Committed as r18.

Changes:
* Anagram filter from r17
* Rhyme fixes from r15/r16
* Test script updated
* Standalone recompiled with above changes
* Dictionary in Windows source is now at 12.3
2010 was the year of the Na'vi.Vivar 'ivong Na'vi!


 
Avatray | NWOTD Sigbars | Sacred's Sigbar Tool | My collection of Avatar merchandise

Tirea Aean

Quote from: Ningey on September 16, 2011, 02:02:45 PM
Quote from: Tirea Aean on September 16, 2011, 01:47:32 PM
I assume that
Quote...$CLIDIR and set a line like "export CLIDIR=<something>"...

would make it so that it installs to whatever directory the terminal is currently in.

This fix seems simple enough, All I'd have to do is add/change a few lines in install.sh, and then update the README.txt file. When I have some time, I'll figure this out and commit.

That would be one possibility, another one (again, not mutually exclusive ;) ) would be to pass a parameter to the installer that specifies the target directory.
This way you would be able to install it either to a user's homedir (that would be how it works right now - with any user) or to a specified dir (which in turn would have to be created if not present) - the latter of which requires superuser privileges but makes it available to any users present on the machine.
The only ramification would be that you would need superuser privileges to update the databases (there should be a way to deal with that one, too).

I'm attempting to find a way to deal with these issues as well - maybe we should sync on that later on to find a solution.

Kìyevame!

Ningey

That'd be great.

If you have interest in joining the dev team just pm me your gmail address.

Ningey

#263
I don't know if I would be that great of a help, though since I won't be able to do anything that often (right now I have to deal with some annoyances, and furthermore there are other projects and pastimes that take up quite a deal of my time).
Anyway, I'm nevertheless working on this problem (I think I have already found a feasible solution for the installer, and right now I'm going to implement it) and once I got that working, I'll let you know.

However, should you still be interested in my help despite my lack of time, please let me know and I'll give you my E-mail address.


"Sawtute ke tsun nivume - fo ke kerame!"
-- Neytiri te Tskaha Mo'at'ite

"There are two things that are infinite: Human stupidity and the universe. However, I'm not yet sure about the universe."
-- Albert Einstein

"He who gives up freedom for security deserves neither and loses both."
-- Benjamin Franklin

Tirea Aean

#264
So I've just gotten the install.sh script right.

Until I notice that vrrtepcli.sh has a LOT of references to ~/.vrrtepcli directory. This is a problem for anyone who does root custom install...

This calls for a new release [1.93] upon completion. Updates to come. Suggestions welcome, as always, and Thanks to all who use and help it to become a better project.

EDIT:

New vrrtepcli version 1.93 for Linux/Mac.

Quote from: ChangeLog.txt
v1.93
vrrtepcli.sh:
    removed title and help-line if an argument is passed.
    removed "by Tirea Aean" in title/help line
scramble.py:
    some comments added, nothing big.
install.sh:
    detect if root user is installing, if so, allow installdir choice.
    use move command for installing instead of copy
uninstall.sh:
    detect if root user is uninstalling, if so, uninstall from custom dir
vrrtepcli.sh:
    now able to run from any dir (which the root user installed it to)
rhyme.py:
    removed generator script codeblock
Updated dictionaries
vrrtepcli_update.sh:
    detect if root user is updating, if so, update accordingly
Updated README.txt

New download at http://code.google.com/p/vrrtepcli/downloads/list

Puvomun

Krr a lì'fya lam sraw, may' frivìp utralit.

Ngopyu ayvurä.

Tirea Aean

There is a problem with the symlink. I need to do more work. For now, don't install as root.

Tirea Aean

Quote from: Ningey on September 15, 2011, 03:00:19 PM
Kaltxì, ma Tirea Aean!

I have installed this shell myself (Linux version), however I needed to rerig the scripts in order to be able to use the CLI from any user.
Maybe the installer should be overhauled in such a fashion that you can specify a target dir (when installing as root), rerig the scripts proper so that they can access the data files in the dir the CLI has been installed in (I applied a hack and replaced any ~/.vrrtepcli by a $CLIDIR and in vrrtepcli.sh inserted an export CLIDIR="<installdir>" at the beginning - which in turn also applies to the updater script as well - and also patched the Python script so that it recognizes the symlink used for accessing the script) and place a symlink into one of the dirs present in $PATH (I have chosen /usr/bin here). The alias won't be necessary any more. ;)

That would be a nice feature indeed.

Kìyevame.

Ningey

Kaltxì ma Ningey, I have interest in applying this fix, I have committed, but today realized that I failed to get the symlink to work if everything was not custom installed to the same directory. I'm wondering how I can apply this fix here to the installer, updater, and uninstaller, and vrrtepcli.sh and get the $PATH symlink to work...can you copypaste your versions of these scripts to the forum in [code][/code] tags? That'd be a big help. :)

Ningey

#268
Kaltxì, ma Tirea Aean

That's strange, indeed. I have patched the installer in such a fashion that it doesn't actually install the files to a dir, but instead displays the command it would have executed.
As far as I can tell everything looks fine (even the symlink creation).

What data have you entered for the data files and the executable dir? The only two reasons I can imagine why the symlink isn't set (correctly) are that either something must have gone awry here (maybe you specified the wrong dir for the symlink?), or you have provided a relative(!) path for the data dir with the script setting the symlink accordingly - however once you cd away from the dir you started the installation in you are busting the link. Unfortunately ln doesn't expand the path you want to have the symlink point at to its absolute form so it remains relative - and cding to another dir makes it relative to the new dir, which in turn causes the symlink to point to nowhere, and you get an error.

I'd rather suggest you hardcoded /usr/bin as the target dir for the symlink since that is where CLI progs are usually placed, so you won't mess things up here, and also make sure that you enter an absolute path for the install directory.

I hope I could help you with that issue.

Ningey

EDIT: A workaround here would be to copy the files as normal, then do something like this:


cd $FILEPATH
ln -s $PWD/vrrtepcli.sh /usr/bin/vrrtepcli


Since $PWD stores the absolute(!) path to the current work dir, you will get the link right even if you provided a relative install path.


"Sawtute ke tsun nivume - fo ke kerame!"
-- Neytiri te Tskaha Mo'at'ite

"There are two things that are infinite: Human stupidity and the universe. However, I'm not yet sure about the universe."
-- Albert Einstein

"He who gives up freedom for security deserves neither and loses both."
-- Benjamin Franklin

Tirea Aean

#269
The failure is the fact that the symlink in /usr/bin or wherever points to the vrrtepcli.sh in the $FILEPATH (dir where data is installed)

The problem is, vrrtepcli.sh relies on the fact that all the data files and scripts are in the same directory. If you run the script from /usr/bin, it will want to have all the stuff there too. but it's just the vrrtepcli.sh and no data. It's the fact that vrrtepcli.sh references its own current directory to run the .py files.

if you run /urs/bin/vrrtepcli, it will look for /usr/bin/vrrtepcli.py which will look for /usr/bin/localizedWords.txt and /usr/bin/metaWords.txt etc etc. This is the problem.

Is there a way to make it so that the /usr/bin/vrrtepcli symlink can just run the $FILEPATH/vrrtepcli.sh such that it knows that all the stuff is in $FILEPATH and not /urs/bin?

EDIT: OH. I think the solution has to do with using absolute paths... :\

Ningey

Quote from: Tirea Aean on September 19, 2011, 10:07:47 AM

...

EDIT: OH. I think the solution has to do with using absolute paths... :\

Srane.

You just copy the files as usual, then cd to the target dir and do a ln -s $PWD/vrrtepcli.sh /usr/bin/vrrtepcli

Then you got all the data and executables together in one dir and the symlink in /usr/bin, exactly as it is supposed to be.

The trick with using $PWD in the symlink (and, rutxe, don't forget the cd beforehand) is that you can specify an installation path relative to your current dir and still get the absolute path.


"Sawtute ke tsun nivume - fo ke kerame!"
-- Neytiri te Tskaha Mo'at'ite

"There are two things that are infinite: Human stupidity and the universe. However, I'm not yet sure about the universe."
-- Albert Einstein

"He who gives up freedom for security deserves neither and loses both."
-- Benjamin Franklin

Tirea Aean

#271
I have solved the issue. No symlinks. Instead, I have it create a 1-liner in /usr/bin which just contains "$FILEPATH/vrrtepcli.sh" and it runs perfectly now.

EDIT: NO it doesnt, I will try that what you have just said instead...

DOUBLE EDIT: No, that doesnt work, that's how it is now.

all data files go where the user tells them to. ($FILEPATH)

a symlink pointing to $FILEPATH/vrrtepcli.sh is placed in /usr/bin

vrrtepcli.sh contains references to Its own directory.

the symlink therefore contanis the same references.

the symlink will look in its own directory for the data files. not in $FILEPATH.

TRIPLE EDIT: The issue was never that the symlink can't find vrrtepcli.sh. the issue IS: not having all the files where the symlink is. that's not what I want. no one wants to put data files in /usr/bin.

TOO MANY EDITS:

I think I got it for real this time. further examination, then a commit.

Blue Elf

One question - how vrrtepcli handles expressions created from two or more words? Seems that only last word is used, see my console output:
C:\WINDOWS>vrrtepcli kxll
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

n. charge, running attack

C:\WINDOWS>vrrtepcli kxll si
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

auxiliary verb, postpositional nonbound verb do, make

C:\WINDOWS>vrrtepcli tìkxey si
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

auxiliary verb, postpositional nonbound verb do, make

C:\WINDOWS>vrrtepcli "tìkxey si"
si""=="-u" was unexpected at this time.

Using quotes doesn't help. Is there way how to find such words?
Oe lu skxawng skxakep. Slä oe nerume mi.
"Oe tasyätxaw ulte koren za'u oehu" (Limonádový Joe)


Tirea Aean

#273
Quote from: Blue Elf on September 20, 2011, 07:01:32 AM
One question - how vrrtepcli handles expressions created from two or more words? Seems that only last word is used, see my console output:
C:\WINDOWS>vrrtepcli kxll
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

n. charge, running attack

C:\WINDOWS>vrrtepcli kxll si
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

auxiliary verb, postpositional nonbound verb do, make

C:\WINDOWS>vrrtepcli tìkxey si
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

auxiliary verb, postpositional nonbound verb do, make

C:\WINDOWS>vrrtepcli "tìkxey si"
si""=="-u" was unexpected at this time.

Using quotes doesn't help. Is there way how to find such words?

you have to do


corey@lilmint:~$ echo eltur tìtxen si | vrrtepcli
Vrrtep CLI v1.93 | Run 'vrrtepcli -h' for usage.

vrrtep:> vin. be interesting, intriguing



for example. This applies to ALL si verbs and multiword constructs alike. It does not know the common phrase section of the dictionary. (For some reason, that stuff is not in the .sql)

EDIT: OH you're on windows... You have to pipe the output from whatever command prints stuff to the console, into vrrtepcli.

DOUBLE EDIT: OR You can just use vrrtepcli with NO arguments, and write it normally inside the program when it prompts you.


corey@lilmint ~ $ vrrtepcli
Vrrtep CLI v1.93 | Run 'vrrtepcli -h' for usage.

vrrtep:> eltur tìtxen si
vin. be interesting, intriguing


Blue Elf

Pipe output to vrrtepcli doesn't work (throws exception), but the second option works well
C:\WINDOWS>echo kxxl si | vrrtepcli
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

vrrtep:> Traceback (most recent call last):
  File "vrrtepcli.py", line 345, in <module>
  File "vrrtepcli.py", line 238, in main
TypeError: unicode() argument 2 must be string, not None

C:\WINDOWS>vrrtepcli
Vrrtep CLI v1.92 by Tirea Aean. run 'vrrtepcli -h' for usage.
Windows version by Swoka Ikran
Standalone version

vrrtep:> kxll si
vin. charge

Oeri tsun tivam, irayo nìtxan
Oe lu skxawng skxakep. Slä oe nerume mi.
"Oe tasyätxaw ulte koren za'u oehu" (Limonádový Joe)


Tirea Aean

it's probably easier that last way anyway. ;) Also, new dictionary set out. And the new Linux/Mac version should work now.

Swoka Ikran

Just pushed r24. It's basically r19-r23 (v1.93) for Windows. No zip files because it needs testing (I especially need the installer tested on Vista/7/8).

Changes:
* Can be installed for all users (see README for details, especially Vista/7/8 users who have UAC enabled)
* Dictionary updated
* Revised README
* Practically rewrote the installer (result of adding "all users" feature)
* -s / -q and -n are now mutually exclusive
* Code clarifications
2010 was the year of the Na'vi.Vivar 'ivong Na'vi!


 
Avatray | NWOTD Sigbars | Sacred's Sigbar Tool | My collection of Avatar merchandise

akiwiguy

I can confirm that the installer works on Win7 x64, tested both user and admin installation.

Swoka Ikran

Quote from: Eltu lefngap 'eveng on September 25, 2011, 10:29:12 PM
I can confirm that the installer works on Win7 x64, tested both user and admin installation.
Cool. It's working on XP, and seeing Vista and 7 are very similar internally, I'd assume Vista's results would be like Win7's. Not concerned about Win8 since that's not even in Beta yet.

I may post zips later today...or if not, tomorrow or Wednesday at latest.
2010 was the year of the Na'vi.Vivar 'ivong Na'vi!


 
Avatray | NWOTD Sigbars | Sacred's Sigbar Tool | My collection of Avatar merchandise

Tirea Aean

I'm working on porting that test.cmd into a test.sh So far, it works, but the $LOG is rather ugly in some tests.