Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[vinz486]

Hi,
it's possible to search via amulecmd?

And then start a download?

My need is write a script that automatically search and download files, reading keywords from a flat txt file.

Eg. like this

(words.txt contains

"search myfile\n"
"download 1\n"     <--- to download first result on list returned from search command
"quit"

)

$cat words.txt | amulecmd


But, first of all, i've noticed that amulecmd is not scriptable (dont check for sanity of STDIN file descriptor?

If scriptable would be very nice using scripts starting with:

#/usr/bin/amulecmd  

[lionel77]

Maybe we should make the forum search button blink -- there are already two existing feature request threads about search functionality in amulecmd...

See here and here.

[stefanero]

and amulecmd can be used in scripts, for example changing up/down speed or shutdown of amule

create a remote.conf -> search the forum to figure out how

and then you can use

amulecmd -c COMMAND

^^ because of the remote.conf you will not be asked for a password, which makes it easy to use in scripts.

stefanero

[lfroen]

IMHO:
* search from amulecmd is bad idea (while implementation is quite easy). I think I mentioned it already in response to feature request.
* amulecmd is not intended to be script processor. It can do "-c command", but can't "-c cmd;cmd".

[indanet]

Hi!

Originally posted by lfroen
IMHO:
* search from amulecmd is bad idea (while implementation is quite easy). I think I mentioned it already in response to feature request.

The post you are talking about can be found here.

There are use cases where searching from console is the only way to go.  I'm running a server at home, to which me and some other people can remotely login.  Right now we're using MLDonkey which can be controlled entirely via console -- but MLDonkey does not have many active developers because it is written in an unpopular language, so I would like to switch to aMule.

From my point of view, the only missing feature in amulecmd right now is the search feature.  Without this feature aMule cannot be used in my scenario which is not as uncommon as you might think!

Regards
indanet

[stefanero]

I think you cannot have to much features, and would also think search is good

[lfroen]

I think you cannot have to much features

This statement is basically wrong. Actually, you can have "too much features". Each new feature inevitably mean potential for new bug. Possible several bugs. Each feature have potential for "what is it for questions". Each new feature have potential for misuse by mistake.
Adding wrong features steals time from fixing/improving importent ones.
I can continue all day long - bottom line is: "script oriented features have lowest priority".

scenario which is not as uncommon as you might think

You have misperseption about meaning of word "common". You think "my friends and my doing such and such, it must be common". You wrong. FYI: only small %% of users knows concept of "remote login". Even smaller %% have idea of "command line". Even smaller find it convinient to use.

P.S.
I do have statistics in my hand, so please, spare me from argument.

[stefanero]

Originally posted by lfroen

I think you cannot have to much features

This statement is basically wrong. Actually, you can have "too much features". Each new feature inevitably mean potential for new bug. Possible several bugs. Each feature have potential for "what is it for questions".

ok so the point it? never add new features to aMule again because it might add new bugs?
you have to be kidding me

Each new feature have potential for misuse by mistake.

hum, call me a smartass, but I doubt anyone could get anythign wrong with teh command -> search

Adding wrong features steals time from fixing/improving importent ones.

I doubt its wronge, sicne so many people already asked for it. And dont say "oh it was only 3posts" some people are smart enought not to repeat what others already asked.

I can continue all day long - bottom line is: "script oriented features have lowest priority".

ok dont make it scriptable, but still having search is still good. It would also make the amulecmd more powerfull then amuleweb in the end. since you have a lot more options already, except for search.

[lfroen]

I doubt its wronge, sicne so many people already asked for it

People posting in forum(s) can not be taken as representative sample in any meaning. Making any conclusion about "how many people wants " based on number of requests in forum have no sence.
So let's stop arguing about well known fact:  more people wants better gui that any CLI utility in case of end-user application. And amule is end-user application.

It's not that I advise against using (or developing) command line appication (amulecmd in this case). It's just matter of priorities. Most of devs (me including) have not much time to spend for amule, so tasks must be prioterized. For me list looks like this:
EC core bugs
amuleweb bugs / features
amulegui bugs / features
amulecmd (no matter what)

[Kry]

lfroen, you're again confusing "I don't want to do it" with "it shouldn't be done"

[Aethereal]

Maybe I'm wrong, but if EC takes the right direction (as in a totally remotely controllable amule/amuled) I suppose it would be indifferent which interface you use for exchange control packets, and aMuleWEB, aMuleGUI and aMuleCMD will end having all the same set of commands, only with a different interface.
Of course in order to EC to become stable, is better not to mess with all the remotes at the same time... some things are really messy (like displaying search results in a console where you haven't scroll abilities) and you don't want to have to rewrite all the function later only because the EC packets it relied on were a beta version now deprecated...
Beside that, I hope someday I'll be able to do anything (including setting file paths) from aMuleGUI on a different PC with different OS...  

[Kry]

Originally posted by Aethereal
Maybe I'm wrong, but if EC takes the right direction (as in a totally remotely controllable amule/amuled) I suppose it would be indifferent which interface you use for exchange control packets, and aMuleWEB, aMuleGUI and aMuleCMD will end having all the same set of commands, only with a different interface.

That's already the case.