bugGNU Octave - Bugs: bug #62282, ls command in 7.1.0 may not...

 
 

bug #62282: ls command in 7.1.0 may not function

Submitter:  Liang Tang <lt1234>
Submitted:  Sun 10 Apr 2022 04:27:05 PM UTC
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  lt1234 Open/Closed:  * Closed
Release:  * 7.1.0 Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Sat 30 Apr 2022 03:59:00 PM UTC, comment #48: 

ls implementation on both Linux and Windows has been much improved.  Marking this issue as Fixed and closing report.  If there are additional specific bugs they should be opened as new bug reports.

Rik <rik5>
Project Administrator
Fri 22 Apr 2022 07:08:11 PM UTC, comment #47: 

For all of us. 

I think I have a better understanding about our ls related discussions now.

We all know that ls is a unix command.  There are a number of -flag go with ls to show the directory contents.   ls is implemented in both Matlab & Octave.  Neither of the two fully implement the unix version. 

However the documented  functionalities for ls from Matlab and Octave are different.  Octave's ls has unique escape sequence specifications that I have not found them existing elsewhere, given that I don't have any access to Matlab or a unix machine. 

My read is that someone in the past defined the Octave ls with features knowing that these features are not necessary compatible with unix or Matlab.  And these differences are not challenged while many other incompatibilities are.  Because specifications are different and not compatible, a successful implementation
of the specification must result in different software features.  So it is expected that things work in one software might not work in the other.  If you have Matlab resources, I expect you will find out most if not all the test cases we had tried so far  will work in Matlab.      However let me suggest that we accept that ls is different and move on. 

I have two questions that I would like to get your help.  Do you know if ls is called internally in Octave?  Do you know if dir is called internally in Octave? Thanks. 

Liang Tang <lt1234>
Fri 22 Apr 2022 06:57:10 PM UTC, comment #46: 

I am right at the folder as what show below.  

`ls *`: list all in the current directory    % correct. files listed. 
`ls \*`: look for a single file or list the content of a folder named `*`   outcome: syntax error at *
`ls .\*`: look for a single file or list the content of a folder named `.*`  % correct.  there is no such file. 
`ls .\\*`: look for a single file or list the content of a folder named `*`
(the same as second command)   outcome: ls: cannot access './*': No such file or directory
`ls ./*`: list all in the current directory (the same as first command)  outcome: list of files. 

I am getting to the point to say that this command is not for me to use.  It is for someone who are more capable. 

Liang Tang <lt1234>
Fri 22 Apr 2022 06:37:22 PM UTC, comment #45: 

`ls *`: list all in the current directory
`ls \*`: look for a single file or list the content of a folder named `*`
`ls .\*`: look for a single file or list the content of a folder named `.*`
`ls .\\*`: look for a single file or list the content of a folder named `*` (the same as second command)
`ls ./*`: list all in the current directory (the same as first command)
`ls D:\Users\Owner\Desktop\BEV\doc\*`: look for a single file or list the content of a folder named `doc*` in the directory `D:\Users\Owner\Desktop\BEV`
`ls D:\Users\Owner\Desktop\BEV\doc\\*`: look for a single file or list the content of a folder named `*` in the directory `D:\Users\Owner\Desktop\BEV\doc`

In all of these examples the same rule applies: If `*` is preceded by `\` it is to be taken as a literal character. Otherwise, it is a wildcard character for an arbitrary number of characters.

Markus Mützel <mmuetzel>
Project Member
Fri 22 Apr 2022 04:56:14 PM UTC, comment #44: 

Markus,

I still need help.  Can you tell me what ls see me trying to do when I type these:

ls *
ls \*
ls .\*
ls .\\*
ls ./*

>> ls D:\Users\Owner\Desktop\BEV\doc\*

ls: cannot access 'D:/Users/Owner/Desktop/BEV/doc\*': No such file or directory

>> ls D:\Users\Owner\Desktop\BEV\doc\\*

ls: cannot access 'D:/Users/Owner/Desktop/BEV/doc/\*': No such file or directory

Liang Tang <lt1234>
Fri 22 Apr 2022 04:30:22 PM UTC, comment #43: 

Your quoted portion of the file still contains the typo (`\[` instead of `\]` in line 83 of the file) that has been fixed in the repository. Other than that it looks pretty similar...

Markus Mützel <mmuetzel>
Project Member
Fri 22 Apr 2022 04:26:57 PM UTC, comment #42: 

Markus, thanks.  Rik's charges are in a mutually exclusive if block with you changes.  The baseline is the file you sent with these updates:

        args = regexprep (args, '(?<!\\)([\*\?])', '"$1"');
        args = regexprep (args, '(?<!\\)\[', '"[');
        args = regexprep (args, '(?<!\\)\[', ']"');
        args = regexprep (args, '(\\.)', '"$1"');

If that is the case, with the latest update, there is nothing on my end will change.  Thanks. 

Liang Tang <lt1234>
Fri 22 Apr 2022 04:04:25 PM UTC, comment #41: 
Markus Mützel <mmuetzel>
Project Member
Fri 22 Apr 2022 03:26:48 PM UTC, comment #40: 

Rik, what is your baseline ls.m?  Thanks. 

Liang Tang <lt1234>
Fri 22 Apr 2022 02:52:45 PM UTC, comment #39: 

I checked in the patch to handle backlashes on UNIX platforms here: http://hg.savannah.gnu.org/hgweb/octave/rev/42cf34140699.

Marking entire report as Ready for Test as a lot of progress has been made on both Windows and Linux.

Rik <rik5>
Project Administrator
Fri 22 Apr 2022 07:01:55 AM UTC, comment #38: 

@Rik: Thanks for checking. Fixed the typo you identified in comment #33 here:
https://hg.savannah.gnu.org/hgweb/octave/rev/d585976cb30a

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 09:21:19 PM UTC, comment #37: 

I'm attaching a patch which fixes the behavior of escape characters on Linux platforms.  With this in place I can now use sequences such as

ls abc\?def

This needs testing before I check it in.

(file #53126)

Rik <rik5>
Project Administrator
Thu 21 Apr 2022 08:55:12 PM UTC, comment #36: 

@Dmitri: I checked in a fix for the failing BIST test here: http://hg.savannah.gnu.org/hgweb/octave/rev/0d06084693dd.

Rik <rik5>
Project Administrator
Thu 21 Apr 2022 08:42:02 PM UTC, comment #35: 

Rik, I don't have a window development environment to try those in comment #33.  Thanks. 

Liang Tang <lt1234>
Thu 21 Apr 2022 07:26:45 PM UTC, comment #34: 

comment #33:

> I checked in a small change to the wording of the documentation for ls and dir (http://hg.savannah.gnu.org/hgweb/octave/rev/0acf9363da34) that was slightly better to my native English-speaking ear.


I think it coincidentally broke some tests in

bp-table.cc-tst

(see e.g. http://buildbot.octave.org:8010/#/builders/9/builds/3078/steps/7/logs/stdio
)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 21 Apr 2022 07:15:29 PM UTC, comment #33: 

I checked in a small change to the wording of the documentation for ls and dir (http://hg.savannah.gnu.org/hgweb/octave/rev/0acf9363da34) that was slightly better to my native English-speaking ear.

However, I now have a question about how well this the escape patterning is working on both Windows and Linux.

For Windows, the escaping of regular expressions is

        ## Exclude glob patterns and escaped characters from quoted part of
        ## FILENAMES string
        args = regexprep (args, '(?<!\\)([*?])', '"$1"');
        args = regexprep (args, '(?<!\\)\[', '"[');
        args = regexprep (args, '(?<!\\)\[', ']"');
        args = regexprep (args, '(\\.)', '"$1"');

It doesn't look to me like this handles the case of ']'.  Could someone test this on Windows?

# In a shell
touch 'abc]def'
# In octave
ls abc\]def

Second question is how escaped characters are supposed to behave on Linux.  I did this

# In a shell
touch 'abc?def'
touch 'abc*def'
touch 'abc[def'

In Octave when I try

octave:1> ls abc\?def
ls: cannot access 'abc\?def': No such file or directory
error: ls: command exited abnormally with status 2

However, that same syntax in the shell works just fine.  So I think there is something wrong on Linux platforms as well.

Rik <rik5>
Project Administrator
Thu 21 Apr 2022 05:25:35 PM UTC, comment #32: 

For comment #30.  There are two links in the message.  I detected only one line  and 2 comments changed in ls.m.   Is this correct?

If yes, these are the results.  I took the ls.m down to a local folder.  ls.m is @ the working folder ./ to generate the results below. 

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4

audio.m  ismidifile.m    mididevinfo.m   midifilewrite.m  midimsgtype.m  midisend.m  private
data     midicontrols.m  midifileinfo.m  midiid.m         midiread.m     midisync.m
doc      mididevice.m    midifileread.m  midimsg.m        midireceive.m  packinfo

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\

audio.m  ismidifile.m    mididevinfo.m   midifilewrite.m  midimsgtype.m  midisend.m  private
data     midicontrols.m  midifileinfo.m  midiid.m         midiread.m     midisync.m
doc      mididevice.m    midifileread.m  midimsg.m        midireceive.m  packinfo

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*

ls: cannot access 'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4\*': No such file or
directory

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\\*

ls: cannot access 'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/\*': No such file or
 directory

Liang Tang <lt1234>
Thu 21 Apr 2022 04:35:17 PM UTC, comment #31: 

Oops. I crossed with your post.

Does it work correctly with the latest version of `ls`?

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 04:33:58 PM UTC, comment #30: 

I pushed a patch that changes the docstring of `ls` here:
https://hg.savannah.gnu.org/hgweb/octave/rev/7d99816e9709

That hopefully makes it a bit easier to understand how it works. 🙂

Also noticed that a recent change broke support for escaped wildcards on Windows. Should be fixed here:
https://hg.savannah.gnu.org/hgweb/octave/rev/6397b6d7c42e

I found a similar section about wildcards in the docstring of `dir`. But I agree that this function should behave more natively. (Don't ask me why. But I guess because `ls` sounds more "POSIX-y" and `dir` does not...)

Instead of changing the behavior of `dir`, I pushed an update to its docstring here:
https://hg.savannah.gnu.org/hgweb/octave/rev/c09fdabaa5b6

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 03:57:22 PM UTC, comment #29: 

Markus, for comment #27, I try to follow the ls document.  Please see below.  Thanks.

This is 7.1.0 with your ls patch.   

>> dir D:\Users\Owner\Desktop\BEV\doc\[*

[Paper] Favilli T., Delogu M., Pugi L., Berzi L. - Functional safety and reliability for innovative vehi
clebraking system and integration with electric traction units (2020).pdf
[Uwe_Kiencke,_Lars_Nielsen]_Automotive_Control_Sys(BookFi.org).pdf

>> ls D:\Users\Owner\Desktop\BEV\doc\\[*

ls: cannot access 'D:/Users/Owner/Desktop/BEV/doc/\[*': No such file or directory

>> ls D:\Users\Owner\Desktop\BEV\doc\\[\*

ls: cannot access 'D:/Users/Owner/Desktop/BEV/doc/\[\*': No such file or directory

This is from 6.3.0

>> dir D:\Users\Owner\Desktop\BEV\doc\[*

[Paper] Favilli T., Delogu M., Pugi L., Berzi L. - Functional safety and reliability for innovative vehi
clebraking system and integration with electric traction units (2020).pdf
[Uwe_Kiencke,_Lars_Nielsen]_Automotive_Control_Sys(BookFi.org).pdf

>> ls D:\Users\Owner\Desktop\BEV\doc\\[*

Volume in drive D is 2nd Drive
 Volume Serial Number is 58EA-7659

 Directory of D:\Users\Owner\Desktop\BEV\doc

[Paper] Favilli T., Delogu M., Pugi L., Berzi L. - Functional safety and reliability for innovative vehi
clebraking system and integration with electric traction units (2020).pdf
[Uwe_Kiencke,_Lars_Nielsen]_Automotive_Control_Sys(BookFi.org).pdf
               2 File(s)      7,964,345 bytes
               0 Dir(s)  103,186,747,392 bytes free

>> ls D:\Users\Owner\Desktop\BEV\doc\\[\*

The system cannot find the file specified.

>>

Liang Tang <lt1234>
Thu 21 Apr 2022 03:28:45 PM UTC, comment #28: 

Markus, for ls functionality, I did not read the document.

By reading it the way it it, ls probably should not be in window OS distribution.  It was meant for a software developer, not for a simple user like me.  It used to be good for me. 

I should give up ls and adapt dir instead. dir must be consistent with DOS.   

Liang Tang <lt1234>
Thu 21 Apr 2022 03:22:53 PM UTC, comment #27: 

Ok. I experimented a little bit and it is difficult to create a file containing `*` or `?` on Windows with only CMD and "board tools". (It's pretty easy from a bash [from Git, MSYS2 or similar] by executing e.g. `touch test*`.)
Files containing `[` or `]` can be created without any third party tools.

Should we always treat `*` and `?` as glob patterns on Windows without the option to escape them? What about `[` and `]`?

I don't really like that this would mean that `ls` would behave differently on Windows. And it would also mean that it would be impossible to use that function with files that contain those characters in their name.
But given that this wasn't possible in prior versions of Octave either and I don't recall whether we had reports about that, it might mean that such files are probably not really common.

If we should decide to go that route, we should adapt the documentation to correctly describe the actual implementation.

Re-opening report.

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 03:02:10 PM UTC, comment #26: 

Let's quote the part of the documentation for `ls` about glob patterns to be able to dissect it here:

>     Filenames are subject to shell expansion if they contain any
>     wildcard characters '*', '?', '[]'.  To find a literal example of a
>     wildcard character the wildcard must be escaped using the backslash
>     operator '\'.


Maybe, I'm misunderstanding. But I'd understand that this means that '*', '?', and characters between braces '[]' are treated as glob patterns. If any of these characters are escaped with a backslash (I don't know why it is called "operator" here), they are treated as literals instead.

If you are executing `ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*`, the asterisk at the end is escaped with a backslash. So, it is treated as a literal asterisk, and `ls` searches for a file (or folder) named `audio-2.0.4*`.
If I understand correctly, you would like that the function recognizes that you didn't mean to escape the asterisk in this case. But how should it decide whether the user meant to escape the asterisk or not?

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 01:56:24 PM UTC, comment #25: 

Markus, pls see if this helps.  Thanks. 

There is a ls code behavior change between 6.3.0 and 7.1.0 for Window OS. The following 7.1.0 results are generated with ls patch you sent.  

------------------------------------------------------------
For 6.3.0, I can see that the Unix directory separator / is rejected, which is Ok from my view point. 

ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\           Yes
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*          Yes
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*.m        Yes

The following ls with / at the end, gives mixed results.  I don't have any issue with this.  / is not a valid folder separator for Window OS.
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/           Yes
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*          No
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*.m        No

-------------------------------------------------------------
For 7.1.0 with the ls patch, the window folder \ separator is rejected, which I think is not a reasonable code behavior.

ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\          Yes
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*         No
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*.m       No

ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/           Yes
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*          Yes
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*.m        Yes

I am bit confused by the following two.  I expected the outcome of the two be the same, rejection or acceptance uniformly.  But they are not. 

This does not work. My understanding from Markus's note, is that audio-2.0.4* file does not exit.  But the folder does exist. I expected to see the list of the files in the folder.
ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*

This works.  It shows the folder contents.
cd C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\
ls audio-2.0.4*

Liang Tang <lt1234>
Thu 21 Apr 2022 10:51:11 AM UTC, comment #24: 

Should have written:
...if functions behave differently depending on the platform on which they are executed unless that is absolutely necessary or there are other good reasons for it.

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 10:46:58 AM UTC, comment #23: 

The result in comment #21 looks correct to me.

I might be misunderstanding it. But the documentation of the `ls` function is pretty clear about it when it comes to glob patterns and their escaped counterparts. If the function behaved differently in previous versions on some platforms, that was probably a bug. Imho, a function should do what their documentation describes or the documentation should be adapted.

That might be a personal preference, but I don't think it is a good idea if functions behave differently depending on the platform on which they are executed.

Like I already wrote earlier, `ls` and `dir` are different functions (with similar applications). If you prefer one over the other, use that one.
Admittedly, I'm struggling to get your point.

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 10:23:28 AM UTC, comment #22: 

This is just for your information.  I might have provided similar info before.  In 6.3.0, this is what I got

>> version

ans = 6.3.0

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*

Volume in drive C has no label.
 Volume Serial Number is AC12-40D4

 Directory of C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4

[.]               ismidifile.m      midifileread.m    midiread.m        [private]
[..]              midicontrols.m    midifilewrite.m   midireceive.m
audio.m           mididevice.m      midiid.m          midisend.m
[data]            mididevinfo.m     midimsg.m         midisync.m
[doc]             midifileinfo.m    midimsgtype.m     [packinfo]
              15 File(s)        130,226 bytes
               6 Dir(s)  32,523,997,184 bytes free

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*

Volume in drive C has no label.
 Volume Serial Number is AC12-40D4

 Directory of C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4

File Not Found

Liang Tang <lt1234>
Thu 21 Apr 2022 09:46:19 AM UTC, comment #21: 

For the topic we are on, I think  \ is a folder separator for window OS, not a part of an escape sequence.  A folder address of ....\...\..\ is given on window.  If the syntax interpreter must follow a different rule which is not compatible with the OS, it is more likely the the interpreter needs to be modified or just declare the incompatibility. 

I did another test.  The behavior is below.   Thanks for looking into this. 

>> cd C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\
>> ls audio-2.0.4*

audio.m  ismidifile.m    mididevinfo.m   midifilewrite.m  midimsgtype.m  midisend.m  private
data     midicontrols.m  midifileinfo.m  midiid.m         midiread.m     midisync.m
doc      mididevice.m    midifileread.m  midimsg.m        midireceive.m  packinfo   

Liang Tang <lt1234>
Thu 21 Apr 2022 09:21:57 AM UTC, comment #20: 

Why? There is a difference in the functions `dir` and `ls`. Both have their valid applications. Why should we remove one of them on one platform? Why should they behave differently on different platforms?

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 09:19:41 AM UTC, comment #19: 

I understand what your position is.  Maybe you should consider to

(1) alias ls with dir for window or
(2) disable ls for window OS. 

Thanks. 

Liang Tang <lt1234>
Thu 21 Apr 2022 09:14:07 AM UTC, comment #18: 

If I understand the documentation correctly, that is expected behavior. There is probably no file named `audio-2.0.4*` (with a literal asterisk in the filename) in that packages folder. So the error message is correct.

Markus Mützel <mmuetzel>
Project Member
Thu 21 Apr 2022 09:10:08 AM UTC, comment #17: 

There are two ls and two dir commands below.  The 2nd ls does not work.  Thanks. 

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*

C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/audio.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/ismidifile.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midicontrols.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/mididevice.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/mididevinfo.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midifileinfo.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midifileread.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midifilewrite.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midiid.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midimsg.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midimsgtype.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midiread.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midireceive.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midisend.m
C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/midisync.m

'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/data':
c_maj_melody.mid  sample.wav

'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/doc':
audio.pdf  audio.texi  functions.texi  gpl.texi  macros.texi

'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/packinfo':
COPYING  DESCRIPTION  INDEX  NEWS

'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4/private':
getvariable.m  readheader.m  setvariable.m  writeheader.m

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*

ls: cannot access 'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4\*': No such file or
directory

>> dir  C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*

audio.m          midicontrols.m   midifileread.m   midimsgtype.m    midisync.m
data             mididevice.m     midifilewrite.m  midiread.m       packinfo
doc              mididevinfo.m    midiid.m         midireceive.m    private
ismidifile.m     midifileinfo.m   midimsg.m        midisend.m

>> dir  C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*

audio.m          midicontrols.m   midifileread.m   midimsgtype.m    midisync.m
data             mididevice.m     midifilewrite.m  midiread.m       packinfo
doc              mididevinfo.m    midiid.m         midireceive.m    private
ismidifile.m     midifileinfo.m   midimsg.m        midisend.m

Liang Tang <lt1234>
Thu 21 Apr 2022 08:39:59 AM UTC, comment #16: 

Imho, the current behavior matches the documentation of the `ls` function in Octave. According to it `\*` is treated as an escaped asterisk in the argument to `ls`.
If users would like to not escape that asterisk, they would need to use forward slash `/*` (also on Windows). E.g.:

ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4/*

Does that work?

Markus Mützel <mmuetzel>
Project Member
Wed 20 Apr 2022 12:39:51 AM UTC, comment #15: 

@Markus: Thoughts on comment #14?

Should '*' at the end be valid?

Offhand, I would say yes since the equivalent on Linux using '/' separator does work.

ls DIR/*

I think you might have to give up on interpreting '\*' as trying to escape the asterisk character.

Rik <rik5>
Project Administrator
Tue 19 Apr 2022 11:34:08 PM UTC, comment #14: 

Hi Rik,

In general, the fix works well. I do see a limitation on *.  I expected the two ls below should have given the same answer.  If I replace ls with dir, the two below both work.   Thanks. 

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\*

ls: cannot access 'C:/Octave/Octave-7.1.0/mingw64/share/octave/packages/audio-2.0.4\*': No such file or
directory

>> ls C:\Octave\Octave-7.1.0\mingw64\share\octave\packages\audio-2.0.4\

audio.m  ismidifile.m    mididevinfo.m   midifilewrite.m  midimsgtype.m  midisend.m  private
data     midicontrols.m  midifileinfo.m  midiid.m         midiread.m     midisync.m
doc      mididevice.m    midifileread.m  midimsg.m        midireceive.m  packinfo

Liang Tang <lt1234>
Tue 19 Apr 2022 10:34:04 PM UTC, comment #13: 

No responses.  Assuming patch worked as expected.  Marking as Fixed and closing report.

Rik <rik5>
Project Administrator
Mon 11 Apr 2022 02:43:20 PM UTC, comment #12: 

I pushed a change to the stable branch here:
https://hg.savannah.gnu.org/hgweb/octave/rev/5044c6918fdf

This should be part of the next minor release Octave 7.2.0.

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Mon 11 Apr 2022 01:04:58 PM UTC, comment #11: 

Markus,

With ls.m in the local folder, it works.  Thanks. 

>> ls C:\Octave\Octave-7.1.0\octave*

C:/Octave/Octave-7.1.0/octave-firsttime.vbs         C:/Octave/Octave-7.1.0/octave-launch.exe
C:/Octave/Octave-7.1.0/octave-launch-firsttime.exe  C:/Octave/Octave-7.1.0/octave.vbs

ls * did not work in 6.3.0.  ls * now also works.  It lists the files in the current folder and its sub-folder. 

Liang Tang <lt1234>
Mon 11 Apr 2022 12:45:17 PM UTC, comment #10: 

That's still not generally correct...

From the docs:

> Filenames are subject to shell expansion if they contain any wildcard characters ‘*’, ‘?’, ‘[]’. To find a literal example of a wildcard character the wildcard must be escaped using the backslash operator ‘\’.


So e.g., `\*` should match a literal asterisk "*".
I'm not sure if this ever worked as documented on Windows...

I'm attaching yet another version of a patch that will hopefully finally get this right.

(file #53073, file #53074)

Markus Mützel <mmuetzel>
Project Member
Mon 11 Apr 2022 11:38:06 AM UTC, comment #9: 

Arrrgh. Did my tests with forward slashes "/" instead of backslashes "\" as the directory separator.

I'm trying to remember why I changed that in the first place. But it was most likely to fix some issue. (And just reverting to "dir" as the backend is probably not an option in that case.)

Could you please check with the attached updated version of the patch? I'm also attaching the changed version of `ls.m` so you don't have to manually edit the file...

Does it work with that version?

(file #53069, file #53070)

Markus Mützel <mmuetzel>
Project Member
Mon 11 Apr 2022 11:14:56 AM UTC, comment #8: 

Hi Markus,

I don't do source control.  So I just cut/paste/delete lines from the patch file into the ls.m file. 

It did not work for me.  I got the same ( cannot access ...) message back. 

Thanks,

LT

Liang Tang <lt1234>
Mon 11 Apr 2022 07:12:46 AM UTC, comment #7: 

I probably broke that with this change:
https://hg.savannah.gnu.org/hgweb/octave/rev/535f97bb5f86

Does the attached patch fix it for you?

(file #53066)

Markus Mützel <mmuetzel>
Project Member
Sun 10 Apr 2022 10:20:41 PM UTC, comment #6: 

Yes.  Dir still work. 

Liang Tang <lt1234>
Sun 10 Apr 2022 09:36:13 PM UTC, comment #5: 

If you use "dir" instead of "ls" that seems to work.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 10 Apr 2022 09:34:28 PM UTC, comment #4: 

To see the bug one can just do

>> ls *
ls: cannot access '*': No such file or directory
>>
>> ls
<Expected output ... deleted ...>

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 10 Apr 2022 09:21:44 PM UTC, comment #3: 

I typically use wild card like ls xxx to find files with name contains xxx.  That is the reason that * is used with ls. 

Because ls used to work with * and I could not see anything in the release note, that I understand, could have caused this change, I put the report in. 

I know that dir xxx still work the same or similarly.  (see below)

dir C:\Octave\Octave-7.1.0\octave*
octave-firsttime.vbs         octave-launch.exe
octave-launch-firsttime.exe  octave.vbs

I tried Rik's suggestion:

>> ls 'C:\Octave\Octave-7.1.0\octave*'

ls: cannot access 'C:\Octave\Octave-7.1.0\octave*': No such file or directory

Is there any Octave option that I can change to bring the old ls feature back?  Thanks. 

Liang Tang <lt1234>
Sun 10 Apr 2022 09:04:21 PM UTC, comment #2: 

I confirm this on Windows 10
The problem is with "*". If you drop it, the output as expected.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 10 Apr 2022 09:00:19 PM UTC, comment #1: 

The backslash character '\' is used to escape the next character.  If you want to avoid that behavior you need to use single quotes around the string you are trying to protect.  See if this works

ls 'C:\Octave\Octave-7.1.0\octave*'

Rik <rik5>
Project Administrator
Sun 10 Apr 2022 04:27:05 PM UTC, original submission:  

The ls command below, in 5.2.0, 6.2.0, and 6.3.0, gave  the same results

>> ls C:\Octave\Octave-7.1.0\octave*

Volume in drive C has no label.
 Volume Serial Number is AC12-40D4

 Directory of C:\Octave\Octave-7.1.0

octave-firsttime.vbs          octave-launch.exe
octave-launch-firsttime.exe   octave.vbs
               4 File(s)         89,382 bytes
               0 Dir(s)  16,988,422,144 bytes free

In 7.1.0, the same command gives the following error message:

>> ls C:\Octave\Octave-7.1.0\octave*

ls: cannot access 'C:\Octave\Octave-7.1.0\octave*': No such file or directory

Liang Tang <lt1234>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53126:  ls.unix.cset added by rik5 (1005B - application/octet-stream)
file #53074:  ls.m added by mmuetzel (5KiB - text/plain)
file #53070:  ls.m added by mmuetzel (4KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lt1234 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-04-30 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-04-22 rik5 StatusIn Progress Ready For Test
    2022-04-21 rik5 Attached File- Added ls.unix.cset, #53126
    2022-04-21 mmuetzel StatusFixed In Progress
        Open/ClosedClosed Open
    2022-04-19 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2022-04-11 mmuetzel StatusPatch Submitted Ready For Test
    2022-04-11 mmuetzel Attached File- Added bug62282-ls-glob-win-v3.patch, #53073
        Attached File- Added ls.m, #53074
    2022-04-11 mmuetzel Attached File- Added bug62282-ls-glob-win-v2.patch, #53069
        Attached File- Added ls.m, #53070
    2022-04-11 mmuetzel Attached File- Added bug62282-ls-glob-win.patch, #53066
        StatusNeed Info Patch Submitted
    2022-04-10 rik5 StatusNone Need Info

    Back to the top


    Powered by Savane 3.9