Handling paths about murex HOT 11 CLOSED

That would hit the spot. As a method, path.is_dir is inherently read-only. The stored property then doesn't have to be read-only, simply private. (Don't know if this helps with implementation at all though '^^)

Good idea

Not necessarily a big problem... But it would come in handy to have a string method or something similar doing to_ascii converting non-ascii to ascii-acceptable values, in case we'd create key names directly after some unknown variable, like a file path... I'm just rambling there.

The end goal is to support Unicode names, such as Chinese characters, so the shell can be used with peoples native languages. Functions et al should already support this, though admittedly I haven't done extensive testing beyond some basic fuzzing. But variable names are still stuck in the dark ages of ASCII. It shouldn't be a big change though.

Or how does $(var) work? Like $(var.some-naughty-key) = stuff ?

At the moment it doesn't work with assignment, but aside from that, yes. eg out $(hello.world) already works. But the end goal would be support for stuff like $(hello.世界)

from murex.

Funny enough I was thinking about this particular use case just last week.

You can split it into an array quite easily using jsplit eg

» $PATH -> jsplit :                                                                                                                                                                                                                   
[
    "/usr/local/sbin",
    "/usr/local/bin",
    "/usr/bin"
]

but there isn't currently a way to join arrays back into a single string (something I'll more than likely add in v3.1 since it's a really easy feature)

However for your particular use case, I don't think updating the value by array index is the safest approach because you're trusting that something doesn't change the ordering of the values in $PATH before your code is reached.

So the safest way in your particular scenario is likely just a regexp replace. eg

$PATH -> regexp s,$HOME/some/thing,$HOME/some/other/thing, -> export $PATH
# ... or ...
$PATH -> sed -e s,$HOME/some/thing,$HOME/some/other/thing, -> export $PATH

At least that way you're $HOME/some/thing will be corrected irrespective of where in $PATH it sits.

There's definitely an opportunity here for a bespoke tool that can manage env vars like these more intelligently though. What that tool might look like, though, I don't yet know.

from murex.

Congratulations on v3.0!

You can split it into an array quite easily using jsplit eg

Yes, jsplit can come in handy there.

regexp

Right, regexp was actually what I was looking for, thank!

However, I wasn't talking about the $PATH variable in my question, but about some path to some file (e.g. /home/user/Documents/sheet.pdf). Such paths could be typed as paths instead of being mere strings, and the new type could be indexable as in:

 /home/user/Documents/dir/sheet.pdf -> format path -> [1..3]
# user/Documents/dir

At least, that was my (rust-biased) thought. But it might not be idiomatic for murex. In the meantime, regexp's solved my case.

from murex.

Congratulations on v3.0!

Thank you :)

However, I wasn't talking about the $PATH variable in my question, but about some path to some file (e.g. /home/user/Documents/sheet.pdf). Such paths could be typed as paths instead of being mere strings, and the new type could be indexable

Interesting idea. You say it might not be idiomatic for murex but it is akin to how JSON (et al) are parsed, eg

» %[1..5] -> set bob
» $bob
[
    1,
    2,
    3,
    4,
    5
]
» $bob[0]
1

so it's just a different document format really:

» out: /home/bob/file.txt -> set: path bob
» $bob
/home/bob.file.txt
» $bob[0]
home

Is that the kind of thing you had in mind?

from murex.

Is that the kind of thing you had in mind?

That totally is!
Cool! Yeah, I was wondering if there was any murex-idiomatic way to make sure something is of type "path" and not string. Like type annotation or stuff... or simply cast?

from murex.

Either would work but type annotations is probably the simpler method. Eg

set path file=/path/to/file.txt

from murex.

Sure! Sorry, I was distracted and had completely forgotten about the fact that you could annotate types in set.

from murex.

@Pascalio

Got a working prototype of this now.

Internally it is stored as a structure, comprising of an array of objects. Each array element is an element the path (ie directory).

The path elements are stored with the following metadata:

• dir (true if a directory)
• root (true if the top level is an absolute path rather than relative. I'm thinking of renaming this though)
• value (name of the path element)

    "example": {
        "DataType": "path",
        "Value": [
            {
                "dir": true,
                "root": true,
                "value": "Users"
            },
            {
                "dir": true,
                "root": false,
                "value": "lmorg"
            },
            {
                "dir": true,
                "root": false,
                "value": "Documents"
            },
            {
                "dir": true,
                "root": false,
                "value": "Documents - lmorg's MacBook Pro"
            },
            {
                "dir": true,
                "root": false,
                "value": "dev"
            }
        ],
        "String": "/Users/lmorg/Documents/Documents - lmorg's MacBook Pro/dev/",

You can query the element or its metadata:

» $PWD.2
Documents

» $PWD.2.value
Documents

» $PWD.2.dir
true

You can also rename elements:

» p = $PWD
» p.1.value = "bob"
» $p
/Users/bob/Documents/Documents - lmorg's MacBook Pro/dev

(you'll notice the new dot syntax. this is a new language addition too: #497 (comment))

from murex.

Brilliant!
Reassigning through dot syntax is exciting, too.

Just wondering, what would happen if you try to
$PWD.1.dir = false ? Can we enforce immutability of this?

I was also thinking that, since it's a bool, dir could read is_dir instead? Cosmetic though...

from murex.

Murex types are pretty basic in what you can and cannot do but that’s because they were originally designed as thin wrappers around POSIX pipes.

However I was thinking the same thing about having read only values within that object. I’m just not (yet) sure how I’d implement that within the existing code base.

for bonus points it would be cool if I could also add methods too, like ‘exists’.

I do agree with your point about the naming of those properties too.

——-

Regarding the dot syntax, it’s worth noting one major limitation (and this comes back to shells being bareword heavy), you can only reference keys which are ASCII alpha, numeric and underscores. So keys that are (for example) hyphens wouldn’t work.

I have a plan for that too:
$(var) syntax. The code for $() is already sat in the develop branch but it doesn’t yet support extended characters.

from murex.

Murex types are pretty basic in what you can and cannot do but that’s because they were originally designed as thin wrappers around POSIX pipes.

Yeah, sure...

I could also add methods too, like ‘exists’.

That would hit the spot. As a method, path.is_dir is inherently read-only. The stored property then doesn't have to be read-only, simply private. (Don't know if this helps with implementation at all though '^^)

Regarding the dot syntax, it’s worth noting one major limitation (and this comes back to shells being bareword heavy), you can only reference keys which are ASCII alpha, numeric and underscores. So keys that are (for example) hyphens wouldn’t work.

Not necessarily a big problem... But it would come in handy to have a string method or something similar doing to_ascii converting non-ascii to ascii-acceptable values, in case we'd create key names directly after some unknown variable, like a file path... I'm just rambling there.

Or how does $(var) work? Like $(var.some-naughty-key) = stuff ?

from murex.