Clojure Задать директорию и вывести список файлов и их размеры

@Mypowerfulbrain · Регистрация: 24.07.2013

Author24 — интернет-сервис помощи студентам

Здравствуйте, дорогие форумчане и гости!
Собственно, задачу Я описал в заголовке.
Интересует: какая функция Lisp возвращает список файлов в заданной директории и чтобы с каждого из них(файлов) можно было вытащить информацию о его размере на диске?
Как найти размер файла Я примерно знаю:

Lisp

1
2
3

(setq somefile (open "C://file/name.txt"))
(file-length somefile)
(close somefile)

Помогите, пожалуйста!

@helter · 06.04.2014, 16:50

Сообщение от Catstail

Поэтому, если в стандарте CL, единственный способ узнать длину файла - это его открыть, то стандарт... неправ.

Может и так, может и нет. А что бы вы предложили вместо?

Стандарт в высокой степени платформонезависим, особенности Unix или Windows в принципе не могли в него включаться. Напомню, что при проектировании принципов работы CL с файловой системой для достижения кроссплатформенности требовались весьма значительные усилия.

Историческое разнообразие файловых систем, существующих в период 70-80 годов, можно легко забыть. Кент Питман, один из ведущих технических редакторов стандарта Common Lisp, описал однажды ситуацию в comp.lang.lisp (Message-ID: sfwzo74np6w.fsf@world.std.com) так:

В момент завершения проектирования Common Lisp господствующими файловыми системами были TOPS-10, TENEX, TOPS-20, VAX VMS, AT&T Unix, MIT Multics, MIT ITS, и это не упоминаю группу систем для мэйнфрэймов. В некоторых системах имена файлов были только в верхнем регистре, в других – смешанные, в третьих – чувствительны к регистру, но с возможностью преобразования (как в CL). Какие-то имели групповые символы (wildcards), какие-то – нет. Одни имели :вверх (:up) в относительных файловых путях, другие – нет. Также существовали файловые системы без каталогов, файловые системы без иерархической структуры каталогов, файловые системы без типов файлов, файловые системы без версий, файловые системы без устройств и т.д.

Если сейчас посмотреть на абстракцию файловых путей с точки зрения какой-нибудь определенной файловой системы, она выглядит нелепо. Но если взять в рассмотрение даже такие две похожие файловые системы, как в Windows и Unix, то вы можете заметить отличия, от которых можно отвлечься с помощью системы файловых путей. Файловые имена в Windows содержат букву диска в то время, как в Unix нет. Другое преимущество владения абстракцией файловых путей, которая спроектирована, чтобы оперировать большим разнообразием файловых систем, которые существовали в прошлом, – ее вероятная способность управлять файловыми системами, которые будут существовать в будущем. Если, скажем, файловые системы с сохранением всех старых данных и истории операций войдут снова в моду, Common Lisp будет к этому готов.

Да, CL готов к файловым системам будущего.

Чем интересен стандарт CL - что его разрабатывал не один умный человек, а несколько умных людей, а потом коллегиально принимали много умных людей. Можно ожидать, что его решения близки к оптимальным.

Вообще, поскольку ФС (и ОС) в принципе трансцендентна по отношению к лиспу, имхо можно было бы отдать взаимодействие с ней на откуп реализациям, такой "минималистичный" вариант. Разработчики стандарта, как обычно, поступили противоположным образом: постарались охватить как можно более широкий класс систем. С другой стороны, реализации действительно могут дать другие пути решения задачи (размер файла): я уже упоминал обращение к ОС, а transformator.t напомнил про использование FFI.

@Catstail · 06.04.2014, 17:25

Сообщение от helter

Может и так, может и нет. А что бы вы предложили вместо?

- выше я уже написал. Повторю: в данном конкретном случае (для win/nix) в реализации открытия потока, open выдавать при первой операции ввода/вывода, а длину брать из элемента оглавления. Это вполне примиряет стандарт с обычной практикой (считать байты не нужно). Ну, а в тех ОС, где длина файла не поддерживается (напр. IBM-370), просто возвращать 0 (там длина файла не нужна).

transformator.t · 06.04.2014, 17:33

Сообщение от Catstail

из элемента оглавления

какого оглавления?

Добавлено через 31 секунду
покажите пример

@Catstail · 06.04.2014, 18:04

Сообщение от transformator.t

какого оглавления?

- директории, где расположен файл. Пример чего показать? Я не обращался к оглавлению директории. Я думаю, что обычная команда dir, без проблем показывающая любое оглавление с длинами файлов, навряд ли открывает каждый файл (хотя могу и ошибаться). Откуда же dir так быстро берет длины файлов? Из оглавления, больше не откуда.

@helter · 06.04.2014, 18:49

Сообщение от Catstail

- выше я уже написал. Повторю: в данном конкретном случае (для win/nix) в реализации открытия потока, open выдавать при первой операции ввода/вывода, а длину брать из элемента оглавления.

А, ну реализации под конкретные ОС - это понятно. Просто в стандарт ничего такого не засунешь.

@castorsky · 07.04.2014, 03:51

Сообщение от Catstail

а длину брать из элемента оглавления

Вы говорите о метаданных файлов.
>

Сообщение от transformator.t

Bash

1 2	# strace -s 512 ls -l etc-last.xz 2>&1 \| grep lstat lstat("etc-last.xz", {st_mode=S_IFREG\|0644, st_size=1220368, ...}) = 0

Сообщение от transformator.t

никаких заголовков не видно

Можно иногда и шлангом прикинуться.

Как-то Вы наперед знаете что будет именно lstat, а не fstat, stat.
>

Lisp

;racket
(define (foo path)
  (let prt ((lst (directory-list path #:build? #t)))
    (cond ((null? lst))
          ((file-exists? (car lst))
           (and (displayln (file-size (car lst))) (prt (cdr lst))))           
          (else (prt (cdr lst))))))

>/me

@Catstail · 07.04.2014, 06:55

Сообщение от castorsky

Вы говорите о метаданных файлов.

- Бога ради! "Хоть горшком назови..."

transformator.t · 07.04.2014, 13:34

castorsky, чего?

@castorsky · 07.04.2014, 14:57

Сообщение от Catstail

- Бога ради! "Хоть горшком назови...

Называя вещи не совими именами Вы даете повод для искажения смысла Ваших слов. Например, так

Сообщение от transformator.t

никаких заголовков не видно:

так

Сообщение от transformator.t

ещё раз глянул:

так

Сообщение от transformator.t

00000019 - это размер, ок, но он расположен не в голове...

так

Сообщение от transformator.t

наверное нужно покурить спецификацию фс

так

Сообщение от transformator.t

какого оглавления?
Добавлено через 31 секунду
покажите пример

Кстати спецификацию фс в данном случае курить не нужно. Достаточно дёрнуть stat (это актуально nix, win, mac), учитывая особенности конкретной платформы. Это так же является ответом на Ваш вопрос

Сообщение от Catstail

Откуда же dir так быстро берет длины файлов? Из оглавления, больше не откуда.

А вот когда мы хотим написать свою stat(conat char *, struct stat * buf), тогда конечно придется покурить спеки фс. Это не утомительно + еще дополнительный скил в навык.
>
transformator.t, если для Вас эти слова обидны, то прошу меня извинить. Поверьте, я не желал Вас оскорбить или высмеять.

Сообщение от castorsky

Можно иногда и шлангом прикинуться. Как-то Вы наперед знаете что будет именно lstat, а не fstat, stat.

@Catstail · 07.04.2014, 15:22

castorsky, согласен. Убедительно.

@helter 4527 / 3521 / 358 Регистрация: 12.03.2013 Сообщений: 6,038
	06.04.2014, 16:50	21
	Сообщение от Catstail Поэтому, если в стандарте CL, единственный способ узнать длину файла - это его открыть, то стандарт... неправ. Может и так, может и нет. А что бы вы предложили вместо? Стандарт в высокой степени платформонезависим, особенности Unix или Windows в принципе не могли в него включаться. Напомню, что при проектировании принципов работы CL с файловой системой для достижения кроссплатформенности требовались весьма значительные усилия. Историческое разнообразие файловых систем, существующих в период 70-80 годов, можно легко забыть. Кент Питман, один из ведущих технических редакторов стандарта Common Lisp, описал однажды ситуацию в comp.lang.lisp (Message-ID: sfwzo74np6w.fsf@world.std.com) так: В момент завершения проектирования Common Lisp господствующими файловыми системами были TOPS-10, TENEX, TOPS-20, VAX VMS, AT&T Unix, MIT Multics, MIT ITS, и это не упоминаю группу систем для мэйнфрэймов. В некоторых системах имена файлов были только в верхнем регистре, в других – смешанные, в третьих – чувствительны к регистру, но с возможностью преобразования (как в CL). Какие-то имели групповые символы (wildcards), какие-то – нет. Одни имели :вверх (:up) в относительных файловых путях, другие – нет. Также существовали файловые системы без каталогов, файловые системы без иерархической структуры каталогов, файловые системы без типов файлов, файловые системы без версий, файловые системы без устройств и т.д. Если сейчас посмотреть на абстракцию файловых путей с точки зрения какой-нибудь определенной файловой системы, она выглядит нелепо. Но если взять в рассмотрение даже такие две похожие файловые системы, как в Windows и Unix, то вы можете заметить отличия, от которых можно отвлечься с помощью системы файловых путей. Файловые имена в Windows содержат букву диска в то время, как в Unix нет. Другое преимущество владения абстракцией файловых путей, которая спроектирована, чтобы оперировать большим разнообразием файловых систем, которые существовали в прошлом, – ее вероятная способность управлять файловыми системами, которые будут существовать в будущем. Если, скажем, файловые системы с сохранением всех старых данных и истории операций войдут снова в моду, Common Lisp будет к этому готов. Да, CL готов к файловым системам будущего. Чем интересен стандарт CL - что его разрабатывал не один умный человек, а несколько умных людей, а потом коллегиально принимали много умных людей. Можно ожидать, что его решения близки к оптимальным. Вообще, поскольку ФС (и ОС) в принципе трансцендентна по отношению к лиспу, имхо можно было бы отдать взаимодействие с ней на откуп реализациям, такой "минималистичный" вариант. Разработчики стандарта, как обычно, поступили противоположным образом: постарались охватить как можно более широкий класс систем. С другой стороны, реализации действительно могут дать другие пути решения задачи (размер файла): я уже упоминал обращение к ОС, а transformator.t напомнил про использование FFI. 0

transformator.t defun 603 / 617 / 44 Регистрация: 30.04.2011 Сообщений: 702
	06.04.2014, 17:33	23
	Сообщение от Catstail из элемента оглавления какого оглавления? Добавлено через 31 секунду покажите пример 0

@Catstail Модератор 36917 / 20471 / 4242 Регистрация: 12.02.2012 Сообщений: 33,837 Записей в блоге: 13
	07.04.2014, 06:55	27
	Сообщение от castorsky Вы говорите о метаданных файлов. - Бога ради! "Хоть горшком назови..." 0

transformator.t defun 603 / 617 / 44 Регистрация: 30.04.2011 Сообщений: 702
	07.04.2014, 13:34	28
	castorsky, чего? 0

@castorsky 1978 / 1082 / 87 Регистрация: 29.11.2013 Сообщений: 3,353
	07.04.2014, 14:57	29
	Сообщение от Catstail - Бога ради! "Хоть горшком назови... Называя вещи не совими именами Вы даете повод для искажения смысла Ваших слов. Например, так Сообщение от transformator.t никаких заголовков не видно: так Сообщение от transformator.t ещё раз глянул: так Сообщение от transformator.t 00000019 - это размер, ок, но он расположен не в голове... так Сообщение от transformator.t наверное нужно покурить спецификацию фс так Сообщение от transformator.t какого оглавления? Добавлено через 31 секунду покажите пример Кстати спецификацию фс в данном случае курить не нужно. Достаточно дёрнуть stat (это актуально nix, win, mac), учитывая особенности конкретной платформы. Это так же является ответом на Ваш вопрос Сообщение от Catstail Откуда же dir так быстро берет длины файлов? Из оглавления, больше не откуда. А вот когда мы хотим написать свою stat(conat char , struct stat buf), тогда конечно придется покурить спеки фс. Это не утомительно + еще дополнительный скил в навык. > transformator.t, если для Вас эти слова обидны, то прошу меня извинить. Поверьте, я не желал Вас оскорбить или высмеять. Сообщение от castorsky Можно иногда и шлангом прикинуться. Как-то Вы наперед знаете что будет именно lstat, а не fstat, stat. 3

@Catstail Модератор 36917 / 20471 / 4242 Регистрация: 12.02.2012 Сообщений: 33,837 Записей в блоге: 13
	06.04.2014, 17:25	22
	Сообщение от helter Может и так, может и нет. А что бы вы предложили вместо? - выше я уже написал. Повторю: в данном конкретном случае (для win/nix) в реализации открытия потока, open выдавать при первой операции ввода/вывода, а длину брать из элемента оглавления. Это вполне примиряет стандарт с обычной практикой (считать байты не нужно). Ну, а в тех ОС, где длина файла не поддерживается (напр. IBM-370), просто возвращать 0 (там длина файла не нужна). 0

@Catstail Модератор 36917 / 20471 / 4242 Регистрация: 12.02.2012 Сообщений: 33,837 Записей в блоге: 13
	06.04.2014, 18:04	24
	Сообщение от transformator.t какого оглавления? - директории, где расположен файл. Пример чего показать? Я не обращался к оглавлению директории. Я думаю, что обычная команда dir, без проблем показывающая любое оглавление с длинами файлов, навряд ли открывает каждый файл (хотя могу и ошибаться). Откуда же dir так быстро берет длины файлов? Из оглавления, больше не откуда. 0

@helter 4527 / 3521 / 358 Регистрация: 12.03.2013 Сообщений: 6,038
	06.04.2014, 18:49	25
	Сообщение от Catstail - выше я уже написал. Повторю: в данном конкретном случае (для win/nix) в реализации открытия потока, open выдавать при первой операции ввода/вывода, а длину брать из элемента оглавления. А, ну реализации под конкретные ОС - это понятно. Просто в стандарт ничего такого не засунешь. 0

@Catstail Модератор 36917 / 20471 / 4242 Регистрация: 12.02.2012 Сообщений: 33,837 Записей в блоге: 13
	07.04.2014, 15:22	30
	castorsky, согласен. Убедительно. 0