Перейти к содержимому
  • 0
rootmaster

как узнать путь до скрипта из него самого

Вопрос

раньше использовал os.getenv("_") но затем окозалось что в rc это не катит(моя модификация rc делает os.setenv("_", path) а стандартная нет)

да и на бибилтеки тоже не катит хотя и библиотеки могут состоять из нескольких файлов использовать это не реально из за этого ограницения

так как быть? есть ли "легальный" способ узнать где лежит скрипт?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Рекомендуемые сообщения

3 часа назад, rootmaster сказал:

раньше использовал os.getenv("_") но затем окозалось что в rc это не катит(моя модификация rc делает os.setenv("_", path) а стандартная нет)

да и на бибилтеки тоже не катит хотя и библиотеки могут состоять из нескольких файлов использовать это не реально из за этого ограницения

Ты используешь getenv не по назначению, отсюда и проблемы. При инициализации библиотек путь к ним не записывается в env, при запуске файлов вручную через filesystem proxy тоже, при чтении rc.d тоже. Это скорее прикладная софтверная фича OpenOS, которую удобно юзать при работе с shell для получения быстрых путей к переменным окружения, и она вовсе не является частью API файловой системы, как может показаться. Поэтому при исполнении файла через shell.execute env будет обновлен, а при исполнении через dofile/loadfile - нет

 

3 часа назад, rootmaster сказал:

так как быть? есть ли "легальный" способ узнать где лежит скрипт?

OpenOS:

shell.resolve(process.info().path)

MineOS:

system.getCurrentScript()

Что угодно, включая EEPROM:

local function getCurrentScriptPath()
  local info

  for runLevel = 0, math.huge do
    info = debug.getinfo(runLevel)

    if info then
      if info.what == "main" then
        return info.source:sub(2, -1)
      end
    else
      error("Failed to get debug info for runlevel " .. runLevel)
    end
  end
end

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 часа назад, ECS сказал:

Ты используешь getenv не по назначению, отсюда и проблемы. При инициализации библиотек путь к ним не записывается в env, при запуске файлов вручную через filesystem proxy тоже, при чтении rc.d тоже. Это скорее прикладная софтверная фича OpenOS, которую удобно юзать при работе с shell для получения быстрых путей к переменным окружения, и она вовсе не является частью API файловой системы, как может показаться. Поэтому при исполнении файла через shell.execute env будет обновлен, а при исполнении через dofile/loadfile - нет

 

OpenOS:


shell.resolve(process.info().path)

MineOS:


system.getCurrentScript()

Что угодно, включая EEPROM:


local function getCurrentScriptPath()
  local info

  for runLevel = 0, math.huge do
    info = debug.getinfo(runLevel)

    if info then
      if info.what == "main" then
        return info.source:sub(2, -1)
      end
    else
      error("Failed to get debug info for runlevel " .. runLevel)
    end
  end
end

 

для openOS нерабочую конструкцию дал, она возвращает первую часть команды которая была выполнена в следствии чего открылась прога

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить на вопрос...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.


×
×
  • Создать...