You should be able to type it in a 'shell', and you should be able to set it on a function/program you call from the shell. But you cant download and run program that automatically references a file by path. This system is different enough a unix style system so I'll try and roughly describe some details (with some shortcuts) of how I imagine it. It is a messaging based data flow system (could be further refined, of course):

- The programs behave somewhat like classes - they define input and output 'slots' (akin to instance attributes). But they don't have access to a filesystem API (or potentially even other services, such as network). Programs can have multiple input and output slots.

- You can instantiate multiple instances of the program (just like multiple running processes for the same executable). Unlike running unix processes, instantiated programs can be persisted (and are by default) - it basically persists a reference to the program and references to the values for the input slots.

- When data is provided to the input slot of an instantiated program (lets call this data binding), the program produces output data in the output slot.

- You can build pipeline of programs by connecting the output slot of one program to the input slot of another. This is how you compose larger programs from smaller programs. This could even contain control and routing nodes so you can construct data flow graphs.

- Separately, there are some data stores, these could be filesystem style or relational or key/value.

The shell isn't a typical shell - it has the capability to compose programs and bind data. It also doesn't execute scripts at all - it can only be used interactively to compose and invoke the program graphs. A shell is bound to a data store - so it has access to the entire data store, but is only used interactively by an authenticated user.

So interactive invocation of a program may look something like this:

   >  /path/to/file1 | some_program | /path/to/file2
   # this invokes some_program, attaches file1 to the input slot, saves the output slot contents to file2.

You could save the instantiated program itself if you want.

   > some_program_for_file1 = [/path/to/file1 | some_program]

Then invoke it any number of times.

   > some_program_for_file1 | /path/to/file3  # runs some_program on existing contents
   (update file1 here...)
   > some_program_for_file1 | /path/to/file4  # runs some_program on new contents
 

With advanced filtering programs, you could define more complex sets of input files.

   > /path/to/folder | filter_program(age>10d, size<1M) | some_program | /path/to/output_folder

You can even persist the instantiated query, and reuse it

   > interesting_files = [/path/to/folder | filter_program(age<1d)]
   > interesting_files | program_one
   > interesting_files | program_two

So that's the rough idea, using an ad-hoc made up syntax for single input/output slot programs.