Re: Grand Unified System Installer (hurd distro) + my taughts and comments - new to hurd contributions, only taking my head out of the sand now.

[Ivan Malone]

On Mon, 2009-07-27 at 02:24 +0200, Samuel Thibault wrote:
> PATH_MAX

For example:
POSIX: PATH_MAX is 255 without the terminating NULL.
SVID2: PATH_MAX is 1023 without the terminating NULL.


#include <stdio.h> 
#include <unistd.h>
#include <errno.h>

int maxpath()
{
 errno = 0;
 long result;

 if ((result = pathconf("/",_PC_PATH_MAX)) == -1)
  {
   if( errno != 0 )
     perror("pathconf() error");
  }
 else
  {
   printf("PATH_MAX is %ld\n", result);
  }
  return 0;
}

Anyway, yeah. I'm thinking there shouldn't be a max_path because we
can't tell how far a path could point to. Especially if you reference
something large outside the scope of your own filesystem. In a system
like hurd I think thats some of the fundamental changes that need to be
addressed in POSIX in my opinion for Hurd to be something more than just
another unix. Most software respects either MAX_PATH or _POSIX_MAX_PATH
and I'm sure (though I've not checked) that many projects prob have
their own constants for max path, some relative to the home directory,
some absolute. 



Isn't PATH_MAX relative to the path given from cwd? or is
_POSIX_PATH_MAX the absolute value. Or does no one agree on this. And
where is the point of POSIX if different distro's treat it differently
or argue over its exact size or meaning. Unless a circumstance dictated
it should be size of X then shouldn't MAX_PATH really be the max path
absolutly possible, regardless of some predefined length. Like with
URL's? (kinda) So, when referencing a object in a path it may be
possible to have command line arguments in the path for processing by an
object or interface of somekind in addition to the right hand side of
commands.

Lets say I do daily backups for five companies remotly. I have 5
scripts. Each of those scripts do the same thing. I might execute the
backups like this

ssh -l backupuser aDomain1
~/sh begin_backup.sh emailto: report@aDomain1.com

ssh -l backupuser aDomain2 
~/sh begin_backup.sh emailto:report@aDomain2.com

and so on

I could even put it in a script on my own pc and do it from there by
executing it. The script could possibly fall into the wrong hands (i
could accidently email it to a newsgroup) and someone has the login
details cuz I had them in plaintext in the script. Whatever. 

But, I'd much rather this

<ls -l /media/RemoteMachines* | grep SomeDomainFilter>/<begin_backup.sh>

In theory. When I type my path, the path could consist of a command like
gpg, ls, grep, if statements, while loops, real paths, relative paths,
conditions.

NOTE: this script wouldn't be valid in current bash

set SEARCH_PATHS="~/<ls -l |grep backup_scripts>/removebackups.sh *.old"
$SEARCH_PATH/rm *.old



or typing on the command line

<ls ~/media/clients/ -l |grep backup_scripts>/removebackups.sh *.old

ls would list all files in /media/clients relative to my home folder
pass it through grep looking for backup_scripts

The path is now an array of paths and where removebackups.sh exists on
each of these locations it would get executed with *.old as a
paramater. 

So, paths would be as dynamic as the command line. 

Both the command line and the path should be able to reference objects,
like filesystems, files, interfaces to http, ftp, secure ssh tunnel,
service of some kind and pass it by passing it the relevent paramaters
or environment variables.

Another example, if you had dozens of clustered machines. Each setup in
an identical fashion. Instead of having to use scripts to execute
repetitive jobs on many machines, or do it manually, or have some other
3rd party do it


Assuming the folder
/home/VirtualMountPoints/

consists of empty folders
        .SomeDomain1/
        .SomeDomain2/
        .SomeDomain3/
        .etc/

Variable:
DynamicMountPoints="ssh -l myloginname <ls /home/VirtualMountPoints/>"

Then I could execute $DynamicMountPoints/etc/init.d/gdm restart

I pass ssh the password just once, and it authenticates me with all
required virtual locations (with long paths that could possibly execede
max_path easily)

I've been fooling around ages ago with a means to do this in Linux but
think I'd like to implement a modified bash meant specificly for hurd. A
user could reference locations as if they were already mounted within
their user environment and given that everything was entered correctly,
they have the proper keys in their keyrings etc, bash would make the
required adjustments and connections to make it possible. It would be as
if they existed in the current filetree. There is much to be modified to
make it all work though, not just bash. I need an interface to mount a
network location - translators to use ftp/sftp/samba/whatever.
Clientside and Server side code added to ssh/ftp/whatever software to
use and respect the interfaces to make it as seamless as possible. 

I'd like this to be the basis of my terminal on the LiveCD (and the
bootable rescue partition) on my Hurd. 


Guess I'll see when it comes to porting some stuff. Funny you mentioned
it really as simple things like this are a worry for me, I'm still
getting to grips with hammer filesystem since this morn. Its really
interesting actually. And I think a good way to cut my teeth on hurd
along with building the LiveCD Distro. 

Those of you working on unionmount? Do you think unionmount could be
made to work this way, or does it already? 

Anyway. One of the many things I'm reading up on. There is alot of stuff
out there on Hurd and I've much to learn. 

Thinking maybe a Wiki approach to documenting hurd and a portage
approach to maintaining packages would suit it better.  Think I'll try
the wiki method to document my progress and see how it goes.