Re: RFE: allow bash to have libraries
John Kearney wrote: ... [large repetitive included text elided...] why not just do something like this? <26 line suggested 'header' elided...> gives you more control anyway, pretty quick and simple. At least 30% of the point of this is to take large amounts of common initialization code that ends up at the front of many or most of my scripts and have it hidden in a side file where it can just be 'included'... Having to add 26 lines of code just to include 20 common lines doesn't sound like a net-gain... I thought of doing something similar until I realized I'd end up with some path-search routine written in shell at the beginning of each program just to enable bash to have structured & hierarchical libraries like any other programming language except maybe BASIC (or other shells) My problem is I keep thinking problems can be solvable in a few lines of shell code. Then they grow... *sigh*...
Re: RFE: allow bash to have libraries
:) :)) Personal best wrote about 1 lines of code which finally became about 200ish to implement a readkey function. Actually ended up with 2 solutions 1 basted on a full bash script vt100 parser weighing in a about 500 lines including state tables and a s00 line hack. Check out http://mywiki.wooledge.org/ReadingFunctionKeysInBash Personally I'd have to say using path to source a moduel is a massive securtiy risk but thats just me. I actually have a pretty complex bash modules hierarchy solution. If anybodys interested I guess I could upload it somewhere if anybodys interested, its just a play thing for me really but its couple 1000 lines of code proabely more like 1+. Its kinda why I started updating Gregs wiwi I noticed I'd found different/better ways of dealing with a lot of problems. Thiing like secured copy/move funtions. Task Servers. Generic approach to user interface interactions. i.e. supports both gui and console input in my scripts. Or I even started a bash based ncurses type system :), like I say some fune still got some performance issues with that one. Or improves select function that supports arrow keys and mouse selection, written in bash. Anybody interested in this sort of thing? On 03/01/2012 11:48 PM, Linda Walsh wrote: > John Kearney wrote: ... [large repetitive included text elided...] > >> why not just do something like this? >> > <26 line suggested 'header' elided...> >> gives you more control anyway, pretty quick and simple. >> >> > At least 30% of the point of this is to take large amounts of > common initialization code that ends up at the front of many or > most of my scripts and have it hidden in a side file where it can > just be 'included'... > > Having to add 26 lines of code just to include 20 common lines > doesn't sound like a net-gain... > > > I thought of doing something similar until I realized I'd end up > with some path-search routine written in shell at the beginning of > each program just to enable bash to have structured & hierarchical > libraries like any other programming language except maybe BASIC > (or other shells) > > My problem is I keep thinking problems can be solvable in a few > lines of shell code. Then they grow... *sigh*... > >
Re: bash 4.2 breaks source finding libs in lib/filename...
On 2/29/12 2:42 PM, Eric Blake wrote: In the middle of the histrionics and gibberish, we have the nugget of an actual proposal (thanks, Eric): [to allow `.' to look anchored relative pathnames up in $PATH] > About the best we can do is accept a patch (are you willing to write it? > if not, quit complaining) that would add a new shopt, off by default, to > allow your desired alternate behavior. Maybe we can have a rational discussion about that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: allow bash to have libraries
On Fri, Mar 2, 2012 at 08:20, John Kearney wrote: > :) :)) > Personal best wrote about 1 lines of code which finally became > about 200ish to implement a readkey function. > > Actually ended up with 2 solutions 1 basted on a full bash script > vt100 parser weighing in a about 500 lines including state tables and > a s00 line hack. > > Check out http://mywiki.wooledge.org/ReadingFunctionKeysInBash > > > Personally I'd have to say using path to source a moduel is a massive > securtiy risk but thats just me. > I actually have a pretty complex bash modules hierarchy solution. > If anybodys interested I guess I could upload it somewhere if anybodys > interested, I just found https://gist.github.com/ a few days ago :) Gist is a simple way to share snippets and pastes with others. All gists are git repositories, so they are automatically versioned, forkable and usable as a git repository. > its just a play thing for me really but its couple 1000 > lines of code proabely more like 1+. > Its kinda why I started updating Gregs wiwi I noticed I'd found > different/better ways of dealing with a lot of problems. > > Thiing like secured copy/move funtions. Task Servers. > Generic approach to user interface interactions. i.e. supports both > gui and console input in my scripts. > Or I even started a bash based ncurses type system :), like I say some > fune still got some performance issues with that one. > > Or improves select function that supports arrow keys and mouse > selection, written in bash. > > Anybody interested in this sort of thing? > I'm interested.
Re: RFE: allow bash to have libraries
https://github.com/dethrophes/Experimental-Bash-Module-System/blob/master/bash/template.sh So can't repeat this enough !play code!!. However suggestions are welcome. If this sort of thing is of interesting I could maintain it online I guess. basically I wan kinda thinking perl/python module libary when I started So what I like trap error etc and print error mesages set nounset Try to keep the files in 2 parts source part and run part. Have a common args handler routine. rediculously comples log output etc timestamped, line file function etc... stack trace on errors color output red for errors etc. silly comples userinterface routines :) I guess just have a look see and try it out. Also note I think a lot of the files are empty/or silly files that should actually be deleted don't have time to go through them now though. I'd also advise using ctags, tagging it and navigating so, its what I do. On 03/02/2012 03:54 AM, Clark J. Wang wrote: > On Fri, Mar 2, 2012 at 08:20, John Kearney > wrote: > >> :) :)) Personal best wrote about 1 lines of code which >> finally became about 200ish to implement a readkey function. >> >> Actually ended up with 2 solutions 1 basted on a full bash >> script vt100 parser weighing in a about 500 lines including state >> tables and a s00 line hack. >> >> Check out http://mywiki.wooledge.org/ReadingFunctionKeysInBash >> >> >> Personally I'd have to say using path to source a moduel is a >> massive securtiy risk but thats just me. I actually have a pretty >> complex bash modules hierarchy solution. If anybodys interested I >> guess I could upload it somewhere if anybodys interested, > > > I just found https://gist.github.com/ a few days ago :) > > Gist is a simple way to share snippets and pastes with others. All > gists are git repositories, so they are automatically versioned, > forkable and usable as a git repository. > > >> its just a play thing for me really but its couple 1000 lines of >> code proabely more like 1+. Its kinda why I started updating >> Gregs wiwi I noticed I'd found different/better ways of dealing >> with a lot of problems. >> >> Thiing like secured copy/move funtions. Task Servers. Generic >> approach to user interface interactions. i.e. supports both gui >> and console input in my scripts. Or I even started a bash based >> ncurses type system :), like I say some fune still got some >> performance issues with that one. >> >> Or improves select function that supports arrow keys and mouse >> selection, written in bash. >> >> Anybody interested in this sort of thing? >> > > I'm interested.
Re: bash 4.2 breaks source finding libs in lib/filename...
On 03/02/2012 02:50 AM, Chet Ramey wrote: > On 2/29/12 2:42 PM, Eric Blake wrote: > > In the middle of the histrionics and gibberish, we have the nugget of an > actual proposal (thanks, Eric): > > [to allow `.' to look anchored relative pathnames up in $PATH] > >> About the best we can do is accept a patch (are you willing to write it? >> if not, quit complaining) that would add a new shopt, off by default, to >> allow your desired alternate behavior. > > Maybe we can have a rational discussion about that. > Or here is a what it sounds as a marginally better idea to me: Bash could start supporting a new environment variable like "BASHLIB" (a' la' PERL5LIB) or "BASHPATH" (a' la' PYTHONPATH) holding a colon separated (or semicolon separated on Windows) list of directories where bash will look for sourced non-absolute files (even if they contain a pathname separator) before (possibly) performing a lookup in $PATH and then in the current directory. Does this sounds sensible, or would it add too much complexity and/or confusion? Regards, Stefano
