~sschwarzer

Trackers

~sschwarzer/ftputil

Last active 19 days ago

~sschwarzer/racket-glossary

Last active 2 months ago

~sschwarzer/raco-exe-multitarget

Last active 9 months ago

~sschwarzer/sudoku-solver

Last active 1 year, 3 months ago

~sschwarzer/todo-txt

Last active 1 year, 6 months ago

~sschwarzer/python_skeleton

Last active 2 years ago

~sschwarzer/vppdiff

Last active 2 years ago

#1 Add checkboxes to show only entries for wanted categories 10 days ago

Comment by ~sschwarzer on ~sschwarzer/racket-glossary

It seems the js-addition style property can be used to include a custom JavaScript file.

#1 Add checkboxes to show only entries for wanted categories 10 days ago

Comment by ~sschwarzer on ~sschwarzer/racket-glossary

Sketch for checkboxes:

[ ] show "basic" category
[ ] show "intermediate" category
[ ] show "advanced" category
[ ] show cross references
[ ] show stubs

To filter by categories, change the current heading approach

@glossary-entry{Something}

  @level-basic

...

to

@glossary-entry["Something" '(basic stub)]{
...}

That way it's easier to generate proper div elements to better support JavaScript filter code.

#153 Infinite recursion in `FTPHost.stat` 19 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

I haven't seen this issue in the automated ftputil tests, which contain several lstat/stat tests, and the issue hasn't been reported otherwise. Therefore, I think it's something special with your environment.

I'm not sure what's causing this. Maybe a Windows junction?

Can you find out more about the situation? For example, can you modify the ftputil code to print the path arguments in the calls? You can use something like print(f"=== _Stat._stat: {path!r}") to distinguish calls in different methods. Note that the path arguments may not be the same in the different methods.

#153 Infinite recursion in `FTPHost.stat` 19 days ago

Ticket created by ~sschwarzer on ~sschwarzer/ftputil

From Simon Cox:

I'm getting infinite recursion with a host.stat call. The path._is_file_system_entity is called by stat, and then calls stat. ftputils v5.0.4 on Python 3.7 on Windows. Stack trace below:

Traceback (most recent call last):
  File "[my module].py", line 40, in <module>
    [my code]
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\host.py",
line 1017, in stat
    return self._stat._stat(path, _exception_for_missing_path)
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\stat.py",
line 846, in _stat
    self._real_stat, path, _exception_for_missing_path
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\stat.py",
line 801, in __call_with_parser_retry
    result = method(*args, **kwargs)
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\stat.py",
line 768, in _real_stat
    lstat_result = self._real_lstat(path, _exception_for_missing_path)
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\stat.py",
line 719, in _real_lstat
    if not self._path.isdir(dirname) and not _exception_for_missing_path:
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\path.py",
line 154, in isdir
    return self._is_file_system_entity(path, "dir")
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\path.py",
line 132, in _is_file_system_entity
    stat_result = self._host.stat(path, _exception_for_missing_path=False)
  File "C:\Users\[username]\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ftputil\host.py",
line 1017, in stat
    return self._stat._stat(path, _exception_for_missing_path)
...
RecursionError: maximum recursion depth exceeded

#152 `ParserError` for newlines in directory or file names 19 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

I don't think it would be a good idea to ignore the "redundant" lines. There are several reasons:

  • The initial line for the file will be incomplete, so the presumed directory or file name usually would refer to a non-existent directory or file.
  • Ignoring "unparsable" lines might come from invalid data in the directory listing or even something like "total 11" lines. (This specific pattern is ignored by the UnixParser.)
  • Automatic parser switching relies on a ParserError for a line that the initially set parser can't parse.

Because of these reasons and because newlines in directory and file names should be very rare, I don't intend to add a heuristic to the parser to join lines.

That said, there's a workaround to at least ignore the subsequent lines that come from multiline directory or file names. It's possible to write custom parsers and set them with set_parser. A custom parser wouldn't be able to join lines, but it would be possible to ignore lines that would usually cause a ParserError by overriding the ignores_line method.

Therefore, the (untested) code would look something like this:

# Parser base class for the format the _server_ uses.
# Either `ftputil.stat.UnixParser` or `ftputil.stat.MSParser`.
parser_base_class = ...
class MyParser(parser_base_class):
    def ignores_line(self, line):
        super_ignores_line = super().ignores_line(line)
        if super_ignores_line:
            return True
        try:
            _ = self.parse_line(line)
        except ftputil.error.ParserError:
            return True
        return False


with ftputil.FTPHost(...) as ftp_host:
    ftp_host.set_parser(MyParser())
    ...

#152 `ParserError` for newlines in directory or file names 19 days ago

Ticket created by ~sschwarzer on ~sschwarzer/ftputil

As Simon Cox describes in these two list posts, a newline in a directory or file name leads to a ParserError.

The reason is that ftputil always gets the contents of a whole directory, which is a (possibly multiline) string, for example

-rw-r--r--. 1 schwa schwa   4036 Aug 22 11:03 file1
-rw-r--r--. 1 schwa schwa   4036 Aug 22 11:03 file
with linebreak
-rw-r--r--. 1 schwa schwa   4036 Aug 22 11:03 file2

Since the parser's parse_line method is called on each line, the with linebreak line causes the ParserError.

#45 Better usability regarding login for page/ticket creations/changes 27 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

This ticket isn't relevant anymore since moving to Sourcehut.

REPORTED RESOLVED CLOSED

#147 ftphost.path.exists isdir return True until ftphost.chdir 27 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

It's unclear whether this is a bug in ftputil or something else. I'd need more information from the reporter to continue, but haven't gotten any feedback since over a year. Therefore, I'm closing this ticket.

REPORTED RESOLVED CLOSED

#141 Broken pipe when downloading several files 27 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

I'm closing this ticket for now. It seems to be about a timeout problem and I'd need more information from the reporter to help. However, I haven't gotten any reply for over a year.

REPORTED RESOLVED CLOSED

#139 FTP/TLS 403 Forbidden Error for Most Operations 27 days ago

Comment by ~sschwarzer on ~sschwarzer/ftputil

I'm closing this ticket since I need more information from the reporter and I haven't gottten a reply since over a year.

REPORTED RESOLVED CLOSED